You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tika.apache.org by "Chris A. Mattmann (Commented) (JIRA)" <ji...@apache.org> on 2012/03/30 16:20:28 UTC

[jira] [Commented] (TIKA-888) NetCDF parser uses Java 6 JAR file and test/compilation fails with Java 1.5, although TIKA is Java 1.5

    [ https://issues.apache.org/jira/browse/TIKA-888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13242368#comment-13242368 ] 

Chris A. Mattmann commented on TIKA-888:
----------------------------------------

Hi Uwe, thanks for reporting this. Unfortunately that version of the NetCDF Java library is published under 1.6, and it was a long process to get the Jar out onto Maven Central (I actually published it there, and became part of the NetCDF community ,helping them modernize their build to Maven, etc. etc.). See: http://www.unidata.ucar.edu/mailing_lists/archives/netcdf-java/2010/msg00129.html for an example of the discussion.

I'm not sure what the problem is having a 1.6 dependency in Tika. We disable the tests for NetCDF java if the code isn't being compiled on a 1.6 platform, so all of the Tika code compiles just fine. And, because of the service provider mechanism that we use to load parser classes, only external users of the tika-parsers library that want to use NetCDF support for scientific data formats (NetCDF, OPeNDAP, HDF, etc.) need to worry about the 1.6 requirement. tika-bundle, and tika-app, (and now tika-server) slurp the jar file up as a dependency, but downstream users can simply use exclusion tactics (via Ivy or Maven) to not include it in their specific software projects.

JDK 1.5 is EOL'ed, so eventually we'll all need to be on 1.6 or better (1.7+) anyways, so I'd favor simply revisiting the discussion I'm about to reference below before changing anything in Tika land or working to try and publish a new NetCDF jar that's 1.5 compat. Jukka and I discussed this in Tika land a while back (November 2010), see here: http://s.apache.org/6ij when we were finding Jenkins issues for Tika builds.

Can't Solr simply use an Ivy exclusion (since I see you guys are moving to Ivy)?
                
> NetCDF parser uses Java 6 JAR file and test/compilation fails with Java 1.5, although TIKA is Java 1.5
> ------------------------------------------------------------------------------------------------------
>
>                 Key: TIKA-888
>                 URL: https://issues.apache.org/jira/browse/TIKA-888
>             Project: Tika
>          Issue Type: Bug
>          Components: parser
>    Affects Versions: 1.0
>            Reporter: Uwe Schindler
>            Assignee: Chris A. Mattmann
>
> Lucene/Solr developers ran this tool before releasing Lucene/Solr 3.6 (Solr 3.6 is still required to run on Java 1.5, see SOLR-3295): http://code.google.com/p/versioncheck/
> {noformat}
> Major.Minor Version : 50.0             JAVA compatibility : Java 1.6 platform: 45.3-50.0
> Number of classes : 60
> Classes are: 
> c:\Work\lucene-solr\.\solr\contrib\extraction\lib\netcdf-4.2-min.jar [:] ucar/unidata/geoloc/Bearing.class
> ...
> {noformat}
> TIKA should use a 1.5 version of this class and especially do some Java 5 tests before releasing (as it's build dependencies says, it's minimum Java5). I tried to compile and run TIKA tests with Java 1.5 -> crash (Invalid class file format).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira