I definitely care about this issue. I like the idea of splitting off a solr-zk module. Few people know that CloudSolrClient can do a pure HTTP mode to get cluster state indirectly from ZK via Solr, thus no necessity of talking with ZK and what that entails architecturally (security concerns).
Whenever someone proposes changes to SolrJ impacting dependencies, we need to be super clear about that; needs it’s own issue or dev list message announcement. Code reviews will help. I can’t stand dependency creep in SolrJ! (FYI I have almost no internet connectivity this week. ) On Mon, Feb 17, 2020 at 7:26 PM Jan Høydahl <[email protected]> wrote: > 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 > > > On Mon, Feb 17, 2020 at 6:44 AM Jan Høydahl <[email protected]> wrote: > >> Hi >> >> According to >> 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 >> > > -- Sent from Gmail Mobile
