[ 
https://issues.apache.org/jira/browse/SOLR-3204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13223920#comment-13223920
 ] 

Ryan McKinley commented on SOLR-3204:
-------------------------------------

Sorry, by 'put classes', i mean that when commons-csv-1.0-SNAPSHOT-r966014.jar 
is in the *runtime* classpath it uses classes in the namespace 
org.apache.commons.csv

By using this namespace, it prevents people from using other dependencies with 
that same package name reliably.  The commons-csv folks are understandably 
upset that that means their jar file does not work as expected within solr.

Consider the case where someone deploys the solr.war file (built by ant) with a 
plugin that uses the current commons-csv.jar from /trunk.  *something* will 
break -- either the CSVRequestHandler or their plugin depending on what is 
first in the classpath.  (I think their plugin would always fail since it is 
loaded second)

I think we have gotten lost in the maven discussion, when the real problem is 
about how our CSV.jar interacts with plugins (or anything else in the *runtime* 
classpath)






                
> 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

Reply via email to