lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benson Margulies (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 21:32:59 GMT

    [ 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:31 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.

Now, if you don't publish one of these, anyone who uses your published artifact will get past
the maven dependency graph -- and then sink or swim based on whether they've made their own
arrangements to get the code into their classpath. I can't help wondering how this helps with
the original complaint of the Common(s)-Folk: if you release a version of Lucene that requires
a forked version of Commons, and you don't change the packages, you're setting up for a classpath
conflict, sooner or later, with or without maven, aren't you?


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?

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.

                  
> 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


Mime
View raw message