I added a comment to https://issues.apache.org/jira/browse/SOLR-599 "Lightweight SolrJ client" From June 2008 (!) Let’s continue discussion there?
Jan > 19. feb. 2020 kl. 16:19 skrev David Smiley <[email protected]>: > > 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] > <mailto:[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] >> <mailto:[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 > > -- > Sent from Gmail Mobile
