This is one of the reasons we should pursue a plugin-bundle based distribution. i.e. one main tarball and multiple smaller plugins, see SOLR-10665 <https://issues.apache.org/jira/browse/SOLR-10665> This effort has a working POC, but it is too big for me to finalise alone, and I don't have a sponsor either.
-- Jan Høydahl, search solution architect Cominvent AS - www.cominvent.com > 19. sep. 2018 kl. 22:25 skrev Shawn Heisey <apa...@elyograg.org>: > > On 9/19/2018 1:48 PM, oddtyme wrote: >> I am helping implement solr for a "downloadable library" of sorts. The >> objective is that communities without internet access will be able to access >> a library's worth of information on a small, portable device. As such, I am >> working within strict space constraints. What are some non-essential >> components of solr that can be cut to conserve space for more information? > > For basic functionality, the entire contrib directory could probably be > removed. That's more than half of the download right there. > > Some of the jars in solr-webapp/webapp/WEB-INF/lib can likely be removed. > Chances are that you won't need the jars starting with "hadoop" - those are > for HDFS support. That's another 11 MB. If you don't need either HDFS or > SolrCloud, you can remove the zookeeper jar, and I think you can also remove > the curator jars. If you're not accessing Solr with a JDBC driver, you won't > need the calcite jars. If you're not dealing with oriental characters (and > sometimes even if you ARE), you can probably do without > lucene-analyzers-kuromoji. > > With careful code analysis, you can probably find other jars that aren't > needed, but there's not a huge amount of space saving to be gained with most > of the others. > > Thanks, > Shawn >
