The netty deps are there solely because they are needed by zookeeper client when talking to zookeeper over the new https transport with netty. So a quick win would be to make a solrj-zk.jar which depends on zookeeper-client.jar along with netty and its other dependencies, and thus keep solrj-core clean of these.
It would be great to be able to choose what HTTP lib to use in SolrJ. Obviously you want Jetty-HTTP2-client to do fancy things such as bring-your-own-client with interceptors and what not, but for the simple case we should be just fine with Java11 client in solrj-core. Looking at the solrj module there are 756 Java classes in there. So we use SolrJ as some common module and perhaps it is a bit too easy to just throw new stuff in there,, not really considering this is all going to end up in every user’s classpath + dependencies? Jan > 17. feb. 2020 kl. 23:24 skrev Robert Muir <[email protected]>: > > Yes why would this library have any dependencies at all? In trunk java 11 is > a minimum, and JDK11+ has HTTP client capable of HTTP/2, https, etc. So > seeing both netty and jetty client libraries makes no sense at all. > > https://docs.oracle.com/en/java/javase/11/docs/api/java.net.http/java/net/http/package-summary.html > > <https://docs.oracle.com/en/java/javase/11/docs/api/java.net.http/java/net/http/package-summary.html> > > > On Mon, Feb 17, 2020 at 6:44 AM Jan Høydahl <[email protected] > <mailto:[email protected]>> wrote: > Hi > > According to > https://mvnrepository.com/artifact/org.apache.solr/solr-solrj/8.4.1 > <https://mvnrepository.com/artifact/org.apache.solr/solr-solrj/8.4.1> SolrJ > now has 29 compile-time dependencies. Those are the ones explicitly mentioned > in ivy.xml and I believe that the number would be even higher if we used > transitive dependencies. > That means that if you want to include SolrJ in a small app for just > searching Solr, you get a ton of dependencies in your project that you may > not need and that increase the chance of collision with other libs in your > all. > > So I want to raise the question whether it is time to take some action here. > > Otions may include: > Get rid of unneeded deps > Explicitly exclude deps from gradle build that we know we do not need > Modularize SolrJ into a solrj-core and solrj-xxx, where solrj-core would be > the minimum anyone would need to do the basics > Look into shading select libs that often cause collisions > > Let the discussion begin :) > > Jan
