[
https://issues.apache.org/jira/browse/SOLR-6806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15203106#comment-15203106
]
Shawn Heisey edited comment on SOLR-6806 at 3/20/16 4:59 AM:
-
Here are the obvious things to move to their own artifacts, and their .zip
sizes (in KB, for precision). I made a stab at a name for the zip version of
the archive.
contrib: 68423KB (solr-contrib-x.x.x.zip)
dist: 17960KB (solr-jars-x.x.x.zip)
docs: 11893KB (solr-docs-x.x.x.zip)
example: 4265KB (solr-examples-x.x.x.zip)
The kuromoji and hadoop jars from WEB-INF/lib could be placed in another
artifact. Not sure what to call it, perhaps solr-extras.
The idea with each of these supporting artifacts is that they would be
extracted to the same location as the main artifact, so they would contain a
similar directory structure. Not sure whether we would omit the solr-x.x.x
top-level directory that is in the main artifact. Most people who have .tgz
experience would expect it to be there, but zip users might be confused.
was (Author: elyograg):
Here are the obvious things to move to their own artifacts, and their .zip
sizes (in KB, for precision). I made a stab at a name for the zip version of
the archive.
contrib: 68423KB (solr-contrib-x.x.x.zip)
dist: 17960KB (solr-jars-x.x.x.zip)
docs: 11893KB (solr-docs-x.x.x.zip)
example: 4265KB (solr-examples-x.x.x.zip)
I would always use the .tgz archives in production, but since the machine where
I'm doing all this experimentation is Windows, this info is all about the
zipfiles.
> 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
