tika-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris A. Mattmann (Commented) (JIRA)" <j...@apache.org>
Subject [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
Date Fri, 30 Mar 2012 14:42:29 GMT

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

Chris A. Mattmann commented on TIKA-888:

bq. We don't use transitive dependencies at the moment, because we want to be sure what libs
are added and for the binary distribution we need to add license notes (which cannot be generated
by Ivy) for every single JAR. So we would simply remove the dependency to ucar.

Gotcha, OK, cool.

bq. The parser is still listed in META-INF, so when a Java 5 users tries to parse a NetCDF
file, he gets a ClassNotFound by the NetCDF parser.

Couldn't you take the Parser out of the file:


(e.g., the Service loading mechanism). If you remove the org.apache.tika.parser.netcdf.NetCDFParser
and org.apache.tika.parser.hdf.HDFParser entries from that file, the user will never reach
the NetCDF or HDF Parser, right? I think you guys can provide your own custom copy of this
file, and make sure it's at the root of the classpath in Solr Cell and then it will take your
guys version over the baked in one for the tika-parsers jar.

bq. it would be good to pass a META-INF like list to the AutoDetectParser (I implemented that
for another non-solr project we use at PANGAEA, where i used the META-INF list of Tika, deleted
all unused parsers and passed them somehow to TIKA)

This sounds cool. How is it different from the service provide mechanism though. I think it's
serving a similar purpose, right?

bq. A good idea for TIKA would be to have several tika-parsers packages, maybe one with "office
document parsers", "images",... Are there any plans to split the parser package?

This was discussed a while back, check out for the thoughts there: https://issues.apache.org/jira/browse/TIKA-686

bq. I tried this a few weeks ago and with JDK 1.5, tests were failing.

Our latest Jenkins build (which I think is locked to 1.5) passes (look at the one before I
started mucking with tika-server):


> 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


View raw message