[
https://issues.apache.org/jira/browse/SOLR-6806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15882799#comment-15882799
]
Shawn Heisey commented on SOLR-6806:
------------------------------------
Glad to see some ideas being generated, and some work getting done. SOLR-9450
will make a big difference in the download size and a HUGE difference in how
long archive extraction takes.
Previous comments cover the pain points pretty well. Here's what I see as
remaining low-hanging fruit:
* Eliminate duplicate jars where possible. Adding a "makedist" script to copy
jars from disparate locations to dist is probably a good idea.
* Compress the licenses into an inner archive so archive extraction is
speedier.
* Split the test framework and dependencies only required for testing into a
separate download.
* Consider splitting large things currently included in the webapp, like the
hadoop integration, into a separate download.
* Consider splitting contrib modules and dependencies into a separate download.
* Decide whether the splits mentioned above would all be in the same file, or
separate files.
> 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
> Attachments: solr-zip-docs-extracted.png, solr-zip-extract-graph.png
>
>
> 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.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
