lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Emmanuel Bourg (Issue Comment Edited) (JIRA)" <j...@apache.org>
Subject [jira] [Issue Comment Edited] (SOLR-3204) solr-commons-csv must not use the org.apache.commons.csv package
Date Tue, 06 Mar 2012 19:29:59 GMT

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

Emmanuel Bourg edited comment on SOLR-3204 at 3/6/12 7:28 PM:
--------------------------------------------------------------

Steven I wasn't referring to you explicitly, but to the Solr community. I didn't know you
actually deployed the artifacts. If you dislike Maven you'll be pleased to learn that it was
a great blow to the Maven integrity :)

I'm glad to hear you are willing to do something, what's your plan? Let me recap the options
currently identified:
# Embed the Commons CSV source files in the core of Solr. That was the purpose of my patch,
but it doesn't solve the issue for the other dependencies (carrot, noggit, uima, jsonic, etc)
# Embed the pacthed dependencies in the main Solr jar and rename the packages with jarjar
or a similar tool. The additional benefit it a reduction of the global distribution size by
keeping only the classes actually used by Solr.
# Keep publishing Solr specific dependencies but after renaming the packages with JarJar
# Import the source of the dependencies and rename the package with the Ant replace task (Tomcat
solution)
# Stop releasing Maven artifacts completely, even Solr core.

Pointing to the 3.5 artifacts is a temporary solution, because:
* the classpath conflicts still exists for projects importing solr-core
* the next time Solr needs a patched unreleased dependency it will be problematic
                
      was (Author: ebourg):
    Steven I wasn't referring to you explicitly, but to the Solr community. I didn't know
you actually deployed the artifacts. If you dislike Maven you'll be pleased to learn that
it was a great blow to the Maven integrity :)

I'm glad to hear you are willing to do something, what's your plan? Let me recap the options
currently identified:
# Embed the Commons CSV source files in the core of Solr. That was the purpose of my patch,
but it doesn't solve the issue for the other dependencies (carrot, noggit, uima, jsonic, etc)
# Embed the pacthed dependencies in the main Solr jar and rename the packages with jarjar
or a similar tool. The additional benefit it a reduction of the global distribution size but
keeping only the classes actually used by Solr.
# Keep publishing Solr specific dependencies but after renaming the packages with JarJar
# Import the source of the dependencies and rename the package with the Ant replace task (Tomcat
solution)
# Stop releasing Maven artifacts completely, even Solr core.

Pointing to the 3.5 artifacts is a temporary solution, because:
* the classpath conflicts still exists for projects importing solr-core
* the next time Solr needs a patched unreleased dependency it will be problematic
                  
> 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-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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message