If you have a 'small' application and you want search, you can embed a lucent index. This is a lower impact dependency graph. Solr is a service. I would suspect the only dependencies *required* are client dependencies. And even those might boil down to a shell equivalent curl + json parser.
As a service, you might have a lot more dependencies. Caching, journaling, flushing,'languaging' in addition to all of the communication/server stuff happening. you might have spidering, re-reindexing and other transitive dependencies in the overall footprint. Then, you could add the underlying cloud support libraries. A service is a complicated thing. On Mon, Feb 17, 2020 at 2:30 PM Robert Muir <[email protected]> wrote: > 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 >> >
