[
https://issues.apache.org/jira/browse/SOLR-3204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13224822#comment-13224822
]
Scott Carey commented on SOLR-3204:
-----------------------------------
{quote}
This is a maven issue. solr-commons-csv only exists to maven.
Otherwise these are just classes inside the war file (essentially an
implementation detail of solr).
{quote}
The java classpath is not an implementation detail if you expect any of your
jars to share a classloader with others. At least not until project Jigsaw is
complete and Solr is using Java 8 modules.
{quote}
Yes of course. But e.g. maven can help to prevent those problems. It will not
allow you to add the same dependency in different versions. The issue we had
caused by our separate release of unreleased package under the solr group-id
was that maven is seeing our repackaged dependency under another artifact id -
so it cannot prevent that a project adds solr-commons-xx, version-foo and
commony-xx, version-bar, because it is two different things.
{quote}
Exactly. If you publish a maven artifact under a custom groupId:artifactId the
sane thing to do is make sure the classes don't overlap with the old one.
Maven guards against duplicate artifacts in the same classpath. Otherwise
users will implicitly get both copies on their classpath too easily.
{quote}
The arguments that this is more than a maven issue are bogus.
Do you take me for a fool?
{quote}
What happens if a non-maven user gets both solr-commons-csv.jar and
commons-csv.jar on their classpath?
{quote}
I think you missed my point?: Changing the Ant build to fix a Maven problem is
a non-starter.
{quote}
Then specify it as <optional>true</optional> or <scope>provided</scope>. If
you publish to maven central a pom.xml that says "Solr must have jar FOO!" and
then complain that it is a "Maven problem" when jar FOO is actually used, then
you've used maven incorrectly.
{quote}
Users would have to either have to a) download the binary release and manually
install the non-Maven artifacts one-by-one in their local or internal
repository (after consulting both the top-level Maven POM and a list of
per-module dependencies that currently only exists in a lib/ directory
listing); or b) download the source release, run ant get-maven-poms, then run
mvn -N -Pbootstrap install. Neither of these fall within the expected level of
effort for Maven users.
{quote}
or C)
you can publish the artifacts, link to them as optional, and users can specify
in their pom's which jar to bring in. This is not that uncommon -- it is the
expected way to deal with slf4j for example, where one and only one of several
options must be chosen at runtime. Same thing with the bytecode re-writing
dependency in Hibernate.
{quote}
-1 from me for using optional dependencies to counter Maven's virality.
{quote}
Please consider this further with option C) above for artifacts that live in a
custom groupId:artifactId namespace but not a custom package.
> 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, 4.0
>
> Attachments: SOLR-3204.patch, SOLR-3204.patch, SOLR-3204.patch,
> SOLR-3204.patch, apache-solr-commons-csv-1.0-SNAPSHOT-r966014.jar,
> 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
