[
https://issues.apache.org/jira/browse/SOLR-8680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15183468#comment-15183468
]
Uwe Schindler edited comment on SOLR-8680 at 3/7/16 7:08 PM:
-------------------------------------------------------------
In fact this is a complete solrj.jar file with all dependencies munged together
without respecting packages and licenses. This is not good practise to have on
Maven Central for several reasons:
- it leads to class path hell, because the user cannot figure out class
duplicates (so if he has slf4j or httpclient in his classpath, by adding the
uber-jar, he would have 2 versions of all class files on classpath, possibly
incompatible versions without knowing). So Uber JARs should use Maven Shade
plugin or the jarjar Ant plugin to rewrite all package names in dependecies to
something like {{org.apache.solr.3rdparty.\*}}; e.g. forbiddenapis does this to
bundle ASM (which is a typical candidate that always breaks in Uber-JARs,
because versions are incompatible to eac other, see
https://github.com/policeman-tools/forbidden-apis/blob/master/build.xml#L361-L380
how to do this). If you do this you can name this file solr-solrj-uber.jar and
also deploy on Maven Central without problems. But you have to place *all*
additional LICENSE files in the META-INF folder (not only the ASF license).
- wont work with Java 9 anyways once modules are there, if you dont rewrite
package names
Just to conclude here: It may also be a good idea for other people to have an
solrj uber JAR on Maven central (which would have no dependencies), because
this helps people who get into conflicts e.g. with httpclient in their
classpath. I have seen this quite often for SolrJ (solrj needs httpclient4 but
another lib requires version 3 -> boom).
Those people could just user solr-solrj-uber.jar and have a solr client without
any dependencies and because all packages are rewritten it wont conflict with
other jars in classpath,
was (Author: thetaphi):
In fact this is a complete solrj.jar file with all dependencies munged together
without respecting packages and licenses. This is not good practise to have on
Maven Central for several reasons:
- it leads to class path hell, because the user cannot figure out class
duplicates (so if he has slf4j or httpclient in his classpath, by adding the
uber-jar, he would have 2 versions of all class files on classpath, possibly
incompatible versions without knowing). So Uber JARs should use Maven Shade
plugin or the jarjar Ant plugin to rewrite all package names in dependecies to
something like {{org.apache.solr.3rdparty.\*}}; e.g. forbiddenapis does this to
bundle ASM (which is a typical candidate that always breaks in Uber-JARs,
because versions are incompatible to eac other, see
https://github.com/policeman-tools/forbidden-apis/blob/master/build.xml#L361-L380
how to do this). If you do this you can name this file solr-solrj-uber.jar and
also deploy on Maven Central without problems. But you have to place *all*
additional LICENSE files in the META-INF folder (not only the ASF license).
- wont work with Java 9 anyways once modules are there, if you dont rewrite
package names
> Distribute JDBC driver as a separate jar
> ----------------------------------------
>
> Key: SOLR-8680
> URL: https://issues.apache.org/jira/browse/SOLR-8680
> Project: Solr
> Issue Type: New Feature
> Reporter: Joel Bernstein
> Attachments: SOLR-8680.patch
>
>
> Currently the JDBC driver comes included with the Solrj libraries. As the
> JDBC driver matures it will be useful to distribute a separate jar which
> includes all of the dependancies, rather then having to include all the Solrj
> dependancies separately. This will make it much easier to install and ship
> with products like JasperSoft, Spotfire and Tableau.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
