[
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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
