lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Høydahl (JIRA) <>
Subject [jira] [Commented] (SOLR-6806) Reduce the size of the main Solr binary download
Date Wed, 19 Aug 2015 10:52:45 GMT


Jan Høydahl commented on SOLR-6806:

bq. Solr ships with lucene-test library (and junit, ant, etc) in dist/test-framework. That's
another 10Mb. I don't think anything in the binary distribution actually relies on it.

According to README.txt {{The Solr test-framework products base classes and utility classes
writting JUnit tests excercising Solr functionality.}} it looks like it was put there to enable
users to write unit tests for their own search application software more easily. But we could
easily get rid of it and add a comment to CHANGES.txt and ref-guide on how to get hold of
the test-framework.

bq. IMO, we don't currently really have off-line documentation. We could cut out the javadoc
without hurting newbies at all, and I think the off-line tutorial could go as well...

+1 to replace the contents of the {{docs}} folder with a simple index.html linking to an online
version of the tutorial and javadocs (save 12Mb)

If we also pursue SOLR-5103 (see my last comment there) we could get rid of the {{contrib}}
folder, saving 69Mb. Instead we could have a step in the docs and tutorials telling people
to install plugins as needed via a simple {{bin/solr}} one-liner. 

> Reduce the size of the main Solr binary download
> ------------------------------------------------
>                 Key: SOLR-6806
>                 URL:
>             Project: Solr
>          Issue Type: Task
>          Components: Build
>    Affects Versions: 5.0
>            Reporter: Shawn Heisey
> There has been a lot of recent discussion about how large the Solr download is, and how
to reduce its size.  The last release (4.10.2) weighs in at 143MB for the tar and 149MB for
the zip.
> Most users do not need the full download.  They may never need contrib features, or they
may only need one or two, with DIH being the most likely choice.  They could likely get by
with a download that's less than 40 MB.
> Our primary competition has a 29MB zip download for the release that's current right
now, and not too long ago, that was about 20MB.  I didn't look very deep, but any additional
features that might be available for download were not immediately apparent on their website.
 I'm sure they exist, but I would guess that most users never need those features, so most
users never even see them.
> Solr, by contrast, has everything included ... a "kitchen sink" approach. Once you get
past the long download time and fire up the example, you're presented with configs that include
features you're likely to never use.
> Although this offers maximum flexibility, I think it also serves to cause confusion in
a new user.
> A much better option would be to create a core download that includes only a minimum
set of features, probably just the war, the example servlet container, and an example config
that only uses the functionality present in the war.  We can create additional downloads that
offer additional functionality and configs ... DIH would be a very small addon that would
likely be downloaded frequently.
> SOLR-5103 describes a plugin infrastructure which would make it very easy to offer a
small core download and then let the user download additional functionality using scripts
or the UI.

This message was sent by Atlassian JIRA

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message