Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@lucene.apache.org
Date: Wed, 7 Mar 2012 21:28:58 +0000 (UTC)
From: "Benson Margulies (Issue Comment Edited) (JIRA)" <jira@apache.org>
To: dev@lucene.apache.org
Message-ID: 
 <1353700822.36297.1331155738133.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <1373623055.25363.1330997397011.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Issue Comment Edited] (SOLR-3204) solr-commons-csv must not
 use the org.apache.commons.csv package
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Benson Margulies edited comment on SOLR-3204 at 3/7/12 9:28 PM:
----------------------------------------------------------------

So, I hear that you all wish that you had more control over the dependencies that you propagate when you publish to maven central. Perhaps I could help?

Option 1, which you've already detected, is to use jarjar or shade so that you can publish your fork of someone else's stuff in your own package namespace fairly painlessly, either storing it inside some other jar of yours or publishing it under your coordinates.

Option 2 is optional dependencies: http://maven.apache.org/guides/introduction/introduction-to-optional-and-excludes-dependencies.html.

This is a way to force the users of your artifacts to explicitly declare some or all of your dependencies, rather than getting them automatically. In other words, virality control.

Option 3 is simply to observe that your users can always use 'exclude' to cut off following some dependency link of yours that doesn't appeal to them.

Does any of this help?

p.s. I don't know much about jarjar, but I know that shade has a lot of fancy options that can, in some cases, compensate for reflection or other problems with the package rename process.

                
      was (Author: bmargulies):
    So, I hear that you all wish that you had more control over the dependencies that you propagate when you publish to maven central. Perhaps I could help?

Option 1, which you've already detected, is to use jarjar or shade so that you can publish your fork of someone else's stuff in your own package namespace fairly painlessly, either storing it inside some other jar of yours or publishing it under your coordinates.

Option 2 is optional dependencies: http://maven.apache.org/guides/introduction/introduction-to-optional-and-excludes-dependencies.html.

This is a way to force the users of your artifacts to explicitly declare some or all of your dependencies, rather than getting them automatically. In other words, virality control.

Option 3 is simply to observe that your users can always use 'exclude' to cut off following some dependency link of yours that doesn't appeal to them.

Does any of this help?
                  
> 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
>            Assignee: Uwe Schindler
>            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: 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