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,