[
https://issues.apache.org/jira/browse/SOLR-3204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13224332#comment-13224332
]
Grant Ingersoll edited comment on SOLR-3204 at 3/7/12 1:45 PM:
---------------------------------------------------------------
More that do it:
Geronimo (Apache) (Digester, Discovery)
JVNet-Hudson (commons-jelly)
com.kenai.nbpwr
ServiceMix (commons-csv)
Apache Directory does this weird thing where they package the Commons jars
inside of another jar. Not sure what that does, but the nested jar is Commons.
Not quite sure how the classloader would deal with that.
Mahout does it for Commons-CLI2 (b/c commons never seems to want to release it)
And that is just me searching for commons.
BTW, I don't actually think the problem is Maven. The problem is Java's
classloader is broken. The way to fix it is to use a classloader that scopes
dependencies properly. Otherwise, this is simply a known problem with Java and
the solution is that one has to be careful about what versions of things one
imports. It's exactly the same issue as when one has two dependencies that
each have dependencies on different versions of commons-lang or Lucene or
whats-it-called.jar.
In other words, I don't think this is worth us doing anything different than
what we are already doing. Except, for seeing if we can upgrade our version of
Commons CSV to an official release as a courtesy.
was (Author: gsingers):
More that do it:
Geronimo (Apache) (Digester, Discovery)
JVNet-Hudson (commons-jelly)
com.kenai.nbpwr
ServiceMix (commons-csv)
Apache Directory does this weird thing where they package the Commons jars
inside of another jar. Not sure what that does, but the nested jar is Commons.
Not quite sure how the classloader would deal with that.
Mahout does it for Commons-CLI2 (b/c commons never seems to want to release it)
And that is just me searching for commons.
BTW, I don't actually think the problem is Maven. The problem is Java's
classloader is broken. The way to fix it is to use a classloader that scopes
dependencies properly. Otherwise, this is simply a known problem with Java and
the solution is that one has to be careful about what versions of things one
imports. It's exactly the same issue as when one has two dependencies that
each have dependencies on different versions of commons-lang or Lucene or
whats-it-called.jar.
In other words, -1 on us doing anything different than what we are already
doing. Except, for seeing if we can upgrade our version of Commons CSV to an
official release as a courtesy.
> solr-commons-csv must not use the org.apache.commons.csv package
> ----------------------------------------------------------------
>
> Key: SOLR-3204
> URL: https://issues.apache.org/jira/browse/SOLR-3204
> Project: Solr
> Issue Type: Bug
> Components: Build
> Affects Versions: 3.5
> Reporter: Emmanuel Bourg
> Priority: Blocker
> Fix For: 3.6
>
> Attachments: SOLR-3204.patch, solr-csv.patch
>
>
> The solr-commons-csv artifact reused the code from the Apache Commons CSV
> project but the package wasn't changed to something else than
> org.apache.commons.csv in the process. This creates a compatibility issue as
> the Apache Commons team works toward an official release of Commons CSV. It
> prevents Commons CSV from using its own org.apache.commons.csv package, or
> forces the renaming of all the classes to avoid a classpath conflict.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
