lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael McCandless (Commented) (JIRA)" <>
Subject [jira] [Commented] (SOLR-3204) solr-commons-csv must not use the org.apache.commons.csv package
Date Wed, 07 Mar 2012 19:36:57 GMT


Michael McCandless commented on SOLR-3204:

How to fix the general problem? Thats why I think that the only proper way to fix the bug
is to attack it at the heart:
Thats the fact that for maven project A to depend upon project B that is not in maven, maven
project A must "publish" some "fake maven release" of project B.

+1, this sums up the Maven issue.

But is it really true?  Is there really no way to stop Maven from
making project A's private deps public?  This is horribly invasive.

CLASSPATH polution is a separate, widespread, longstanding and very
real issue. I don't think jarjar'ing every dependency Solr (or our
modules, contribs, etc.) is a good general solution.

But I think it's OK in this case... progress not perfection. Your
patch looks good Uwe, thanks!

> solr-commons-csv must not use the org.apache.commons.csv package
> ----------------------------------------------------------------
>                 Key: SOLR-3204
>                 URL:
>             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-3204.patch, SOLR-3204.patch, apache-solr-commons-csv-1.0-SNAPSHOT-r966014.jar,
rule.txt, rule.txt, 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:!default.jspa
For more information on JIRA, see:


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message