[
https://issues.apache.org/jira/browse/SOLR-6806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15205470#comment-15205470
]
Shawn Heisey commented on SOLR-6806:
------------------------------------
{quote}
as Doug once wisely pointed out...
bq. While you might be somewhat annoyed by the extra baggage, how much harder
does it really make your life?
{quote}
I think this is an excellent point and completely relevant for Lucene -- a
development library. The majority of people interested in downloading Lucene
are developers and can be painted more or less with the "expert" brush.
Looking at the various pieces in the Lucene download, I don't see an obvious
way to decide which modules would be useless to a large cross-section of users.
I think that Doug's advice is less relevant for Solr. It's an application that
attracts a lot of novice users who might not have *ANY* idea what they are
doing. The example configs include large amounts of Solr's extended
functionality, which is a little overwhelming for expert users, and a LOT
overwhelming for the novice. A large cross-section of users will only need
core functionality, and maybe DIH so they can import from their database.
If Solr were split into a 25 MB main archive with examples illustrating core
functionality, an 11MB docs archive, and an extras archive weighing in around
100 MB, that would be awesome. Users can check the README or the reference
guide to see if they need any functionality in the extras archive.
> Reduce the size of the main Solr binary download
> ------------------------------------------------
>
> Key: SOLR-6806
> URL: https://issues.apache.org/jira/browse/SOLR-6806
> 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
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
