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 classpath?
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.
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.