Yes, I've been monitoring that issue. So once TIKA-1581 is resolved we can upgrade to the newer Tika version together with the proper jhighlight package. If that happens before 5.1 is out, all the better.
Shai On Fri, Mar 27, 2015 at 2:32 AM, Karl Wright <[email protected]> wrote: > The jhighlight people just released a 1.0.2 jar which fixes the problem. > It has a different path in Maven, but otherwise it is compatible. See: > https://github.com/codelibs/jhighlight/issues/4 > > Karl > > On Thu, Mar 26, 2015 at 3:09 PM, Shai Erera <[email protected]> wrote: > >> OK I opened SOLR-7317. >> >> Shai >> >> On Thu, Mar 26, 2015 at 8:58 PM, Upayavira <[email protected]> wrote: >> >>> We should remove it. It would not be a good thing to knowingly release >>> incompatible code. Then, upgrade to the latest Tika when we can. >>> >>> Upayavira >>> >>> On Thu, Mar 26, 2015, at 04:41 PM, Steve Rowe wrote: >>> > +1 to remove. >>> > >>> > > On Mar 26, 2015, at 4:43 AM, Shai Erera <[email protected]> wrote: >>> > > >>> > > Looks like 5.1 release process will start soon - should we remove >>> this .jar before the release? I see there's some progress on TIKA-1581, but >>> it doesn't look like it's going to be resolved that soon. >>> > > >>> > > Shai >>> > > >>> > > On Fri, Mar 20, 2015 at 2:59 PM, Karl Wright <[email protected]> >>> wrote: >>> > > 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 <[email protected]> >>> 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 <[email protected]> >>> 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 <[email protected]> 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 <[email protected]> >>> 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 <[email protected]> >>> 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: [email protected] >>> > > For additional commands, e-mail: [email protected] >>> > > >>> > > >>> > > >>> > > >>> > > >>> > >>> > >>> > --------------------------------------------------------------------- >>> > To unsubscribe, e-mail: [email protected] >>> > For additional commands, e-mail: [email protected] >>> > >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> >> >
