lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Uwe Schindler (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 Wed, 07 Mar 2012 15:30:58 GMT

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

Uwe Schindler edited comment on SOLR-3204 at 3/7/12 3:30 PM:
-------------------------------------------------------------

{quote}
bq. How we do this is a different issue: We can only rename all classes in that jar-file and
republish it (but then we have to change our import statements in our code – I would prefer
this), or we jarjar the whole Solr distribution after the complete build.

It's preferable to post process the Solr jar rather than renaming the packages imported in
the source code. That's less intrusive and let you upgrade to the official fixed dependency
more easily.
{quote}

That's our committers decision. The fact here is, that Solr or even Lucene is not just a WAR
file, its consisting of lot's of unrelated JAR artifacts and all of them should live on its
own, so a user can remove features he does not need. So I prefer to "transform" those "changed"
artifacts separately to private "namespace" and simply change maybe 3 import statements (I
can even use "sed" for that).
                
      was (Author: thetaphi):
    {quote}
{quote}
How we do this is a different issue: We can only rename all classes in that jar-file and republish
it (but then we have to change our import statements in our code – I would prefer this),
or we jarjar the whole Solr distribution after the complete build.
{quote}

It's preferable to post process the Solr jar rather than renaming the packages imported in
the source code. That's less intrusive and let you upgrade to the official fixed dependency
more easily.
{quote}

That's our committers decision. The fact here is, that Solr or even Lucene is not just a WAR
file, its consisting of lot's of unrelated JAR artifacts and all of them should live on its
own, so a user can remove features he does not need. So I prefer to "transform" those "changed"
artifacts separately to private "namespace" and simply change maybe 3 import statements (I
can even use "sed" for that).
                  
> 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message