I suspect that the classes in question are in fact *not* used by Tika in any capacity, but they are in the jar nonetheless. So one solution would be to simply repackage the jar. I'd like to see what the Tika team says.
Karl On Fri, Mar 20, 2015 at 7:47 AM, Shai Erera <ser...@gmail.com> wrote: > although it might be easier to work with Tika to fix that and then upgrade >> again. >> > > If jhighlight was brought into Solr distribution as a transitive > dependency then you're right, but since we pull it in explicitly (even if > for runtime purposes only), I think we should remove it, whether Tika > corrects the problem or not. We can put a note in our NOTICE file for users > to download the jar themselves until Tika fixes the problem. > > If people agree, I will remove it from our code. > > Shai > > On Fri, Mar 20, 2015 at 10:40 AM, Karl Wright <daddy...@gmail.com> wrote: > >> I have created a ticket: TIKA-1581. ManifoldCF also has a Tika >> dependency, so thank you for noting the problem. >> >> Karl >> >> >> On Fri, Mar 20, 2015 at 4:03 AM, Upayavira <u...@odoko.co.uk> wrote: >> >>> You are right -both projects need to remove it, although it might be >>> easier to work with Tika to fix that and then upgrade again. >>> >>> Upayavira >>> >>> On Fri, Mar 20, 2015, at 05:26 AM, Shai Erera wrote: >>> > Sorry for the spam, just wanted to note that this dependency was added >>> by >>> > Steve in SOLR-6130 to resolve improper Tika 1.4->1.5 upgrade. >>> > >>> > The core issue lies with Tika IMO (they shouldn't rely on LGPL code >>> too I >>> > believe), but I am not sure if it's OK that we distribute this .jar >>> > ourselves. >>> > >>> > Shai >>> > >>> > On Fri, Mar 20, 2015 at 7:17 AM, Shai Erera <ser...@gmail.com> wrote: >>> > >>> > > One update, I did find this dependency is explicitly set in >>> > > solr/contrib/extraction/ivy.xml, under the Tika dependencies section: >>> > > >>> > > <!-- Tika dependencies - see >>> > > >>> http://tika.apache.org/1.3/gettingstarted.html#Using_Tika_as_a_Maven_dependency >>> > > --> >>> > > <!-- When upgrading Tika, upgrade dependencies versions and add >>> any >>> > > new ones >>> > > (except slf4j-api, commons-codec, commons-logging, >>> > > commons-httpclient, geronimo-stax-api_1.0_spec, jcip-annotations, >>> xml-apis, >>> > > asm) >>> > > WARNING: Don't add netcdf / unidataCommon (partially LGPL >>> code) >>> > > --> >>> > > ... >>> > > <dependency org="com.uwyn" name="jhighlight" >>> > > rev="${/com.uwyn/jhighlight}" conf="compile"/> >>> > > >>> > > So it does seem like needed by Tika only and I guess it's a runtime >>> > > dependency, so if we don't want to release this LGPL library, we can >>> omit >>> > > it and put a section in the NOTICE file? >>> > > >>> > > Shai >>> > > >>> > > On Fri, Mar 20, 2015 at 7:11 AM, Shai Erera <ser...@gmail.com> >>> wrote: >>> > > >>> > >> Hi >>> > >> >>> > >> Solr's contrib/extraction contains jhighlight-1.0.jar which declares >>> > >> itself as dual CDDL or LGPL license. However, some of its classes >>> are >>> > >> distributed only under LGPL, e.g. >>> > >> >>> > >> com.uwyn.jhighlight.highlighter. >>> > >> CppHighlighter.java >>> > >> GroovyHighlighter.java >>> > >> JavaHighlighter.java >>> > >> XmlHighlighter.java >>> > >> >>> > >> I downloaded the sources from Maven ( >>> > >> >>> http://search.maven.org/remotecontent?filepath=com/uwyn/jhighlight/1.0/jhighlight-1.0-sources.jar >>> ) >>> > >> to confirm that, and also found this SVN repo: >>> > >> http://svn.rifers.org/jhighlight/tags/release-1.0, though the >>> project's >>> > >> website seems to not exist anymore ( >>> https://jhighlight.dev.java.net/). >>> > >> >>> > >> I didn't find any direct usage of it in our code, so I guess it's >>> > >> probably needed by a 3rd party dependency, such as Tika. Therefore >>> if we >>> > >> e.g. omit it, things will compile, but may fail at runtime. >>> > >> >>> > >> Is it OK that we distribute this .jar? >>> > >> >>> > >> Shai >>> > >> >>> > > >>> > > >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >>> For additional commands, e-mail: dev-h...@lucene.apache.org >>> >>> >> >
