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