lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Scott Carey (Commented) (JIRA)" <>
Subject [jira] [Commented] (SOLR-3204) solr-commons-csv must not use the org.apache.commons.csv package
Date Wed, 07 Mar 2012 23:12:58 GMT


Scott Carey commented on SOLR-3204:

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).

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.

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.

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.

The arguments that this is more than a maven issue are bogus.
Do you take me for a fool?

What happens if a non-maven user gets both solr-commons-csv.jar and commons-csv.jar on their

I think you missed my point?: Changing the Ant build to fix a Maven problem is a non-starter.

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.

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.

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.

-1 from me for using optional dependencies to counter Maven's virality.

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:
>             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:!default.jspa
For more information on JIRA, see:


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message