Re: jhighlight-1.0 contains LGPL-only files
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 daddy...@gmail.com 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 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
Re: jhighlight-1.0 contains LGPL-only files
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 daddy...@gmail.com 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 ser...@gmail.com wrote: OK I opened SOLR-7317. Shai On Thu, Mar 26, 2015 at 8:58 PM, Upayavira u...@odoko.co.uk 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 ser...@gmail.com 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 daddy...@gmail.com 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 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?
Re: jhighlight-1.0 contains LGPL-only files
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 ser...@gmail.com 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 daddy...@gmail.com 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 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 - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: jhighlight-1.0 contains LGPL-only files
+1 to remove. On Mar 26, 2015, at 4:43 AM, Shai Erera ser...@gmail.com 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 daddy...@gmail.com 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 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 - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: jhighlight-1.0 contains LGPL-only files
OK I opened SOLR-7317. Shai On Thu, Mar 26, 2015 at 8:58 PM, Upayavira u...@odoko.co.uk 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 ser...@gmail.com 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 daddy...@gmail.com 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 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 - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail:
Re: jhighlight-1.0 contains LGPL-only files
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 ser...@gmail.com wrote: OK I opened SOLR-7317. Shai On Thu, Mar 26, 2015 at 8:58 PM, Upayavira u...@odoko.co.uk 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 ser...@gmail.com 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 daddy...@gmail.com 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 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
Re: jhighlight-1.0 contains LGPL-only files
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
Re: jhighlight-1.0 contains LGPL-only files
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
Re: jhighlight-1.0 contains LGPL-only files
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
Re: jhighlight-1.0 contains LGPL-only files
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
jhighlight-1.0 contains LGPL-only files
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
Re: jhighlight-1.0 contains LGPL-only files
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
Re: jhighlight-1.0 contains LGPL-only files
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