+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]

Reply via email to