[jira] [Commented] (SOLR-6806) Reduce the size of the main Solr binary download
[ https://issues.apache.org/jira/browse/SOLR-6806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16088203#comment-16088203 ] Jan Høydahl commented on SOLR-6806: --- Created sub task SOLR-11087 for the jar duplicates issue > 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.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6806) Reduce the size of the main Solr binary download
[ https://issues.apache.org/jira/browse/SOLR-6806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15883034#comment-15883034 ] Alexandre Rafalovitch commented on SOLR-6806: - [~risdenk] Do the jars have to be all together in the solrj-lib though? I was trying to say that the jars were already present but in different directories (web-inf, dist, etc). The important knowledge is *which jars* are the minimal set required for SolrJ. So, if there is a document that lists them clearly, it may be enough. And I am guessing that document is already somewhere in the build instructions, we can just expose it in different ways from copying actual jars. And if you do uber-jar for solrj, you could still pull those jars automatically from wherever the primary copies are. > 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6806) Reduce the size of the main Solr binary download
[ https://issues.apache.org/jira/browse/SOLR-6806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15882859#comment-15882859 ] Jan Høydahl commented on SOLR-6806: --- The downloader just needs to * Know what version we have, so we can download corresponding ver * Find nearest Apache mirror with http://www.apache.org/dyn/closer.lua/lucene/solr?preferred=true * Attempt download of archive, if 404, revert to main dist site, then to archive * Download checksum from the archive and validate * Unzip The bigger issue here I guess is to start releasing more artifacts. We then get source.zip/tgz, bin.zip/tgz, contrib.zip/tgz + .asc, .sha files for each version and more work for RMs. > 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6806) Reduce the size of the main Solr binary download
[ https://issues.apache.org/jira/browse/SOLR-6806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15882850#comment-15882850 ] Kevin Risden commented on SOLR-6806: One of the main issues with solrj-lib is that you have to include it all if you want a third party program to work with Solr that doesn't have maven. An example is the JDBC piece in Solr. There was an issue about trying to distribute a single jar for SolrJ so that might even help having solrj-lib? SOLR-8680 Maven Central doesn't help download all dependencies of solr-solrj if you aren't using Maven to compile. There is no shaded or uber jar on Maven for solr-solrj. > 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6806) Reduce the size of the main Solr binary download
[ https://issues.apache.org/jira/browse/SOLR-6806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15882844#comment-15882844 ] Alexandre Rafalovitch commented on SOLR-6806: - Do we have a document on what libs are supposed to go into what directory. I admit this is a total black box issue for me. I do agree with Jan though that ease of use is the primary concern. So, I would focus first on the things that are just not used at all or not used by the people running Solr as the search engine (javadocs, test libraries, maybe some of the contribs that are not trivial to integrate and we don't provide examples for, etc). DIH - to me -is a complex story. It really needs to be cleaned up/replaced instead of making it more core. But the discussions don't really get anywhere so far. With solrj-lib, could we instead have a README file that points to what jars are required from other already-existing locations? Because the easiest way to get SolrJ is with Maven dependency anyway (right?) and that already manages the dependencies by the reference. > 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6806) Reduce the size of the main Solr binary download
[ https://issues.apache.org/jira/browse/SOLR-6806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15882836#comment-15882836 ] Shawn Heisey commented on SOLR-6806: [~janhoy], you make some good points. If we can build a reliable and fully scripted download mechanism, we solve multiple problems. > 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6806) Reduce the size of the main Solr binary download
[ https://issues.apache.org/jira/browse/SOLR-6806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15882832#comment-15882832 ] Shawn Heisey commented on SOLR-6806: bq. I think the whole solrj-client folder is full of duplicate libraries. Yes, dist/solrj-lib is comprised of duplicates, taking 6MB of space. It would be one of the things copied by the makedist script I mentioned. I still think that the main DIH code and jar should be moved into core. The extras probably should remain outside, especially because the dependencies are not trivial in size. I do find it confusing that the contrib jars are in dist, but their dependencies are in contrib. Seems like they should be together in contrib. > 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6806) Reduce the size of the main Solr binary download
[
https://issues.apache.org/jira/browse/SOLR-6806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15882830#comment-15882830
]
Jan Høydahl commented on SOLR-6806:
---
A problem with {{makedist.sh}} is that you don't support the usecase where
people have scripted download of solr-x.y.tgz, untar, copy dist to somewhere.
Regarding making more release artifacts such as {{solr-contribs-6.4.1.tgz}}
etc, that would help a lot on download size but hurt ease of testing all
features for newbies. That could be easened by a {{java -jar bin/downloader.jar
contrib}} command bundled that would go online, fetch the corresponding contrib
artifact and unzip it into {{$SOLR_TIP/contrib}}. The same approach could be
taken for compiling the dist folder, getting the test dependencies, javadocs mm
without needing to implement a full plugin architecture from day one. I still
think the ideas in SOLR-5103 is a superior long-term plan though :)
> 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6806) Reduce the size of the main Solr binary download
[ https://issues.apache.org/jira/browse/SOLR-6806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15882806#comment-15882806 ] Alexandre Rafalovitch commented on SOLR-6806: - I think the whole solrj-client folder is full of duplicate libraries. Perhaps it is necessary, but it is certainly something to keep a note about. > 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6806) Reduce the size of the main Solr binary download
[ https://issues.apache.org/jira/browse/SOLR-6806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6806) Reduce the size of the main Solr binary download
[
https://issues.apache.org/jira/browse/SOLR-6806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15882709#comment-15882709
]
Jan Høydahl commented on SOLR-6806:
---
Also, {{commons-collections-3.2.2.jar}} is in WEB-INF/lib as well as in
contrib/velocity/lib, no need for that. (0,5Mb)
{{commons-io}}, {{httplilient}} and more is in WEB-INF and dist/solrj
{{icu4j-56.1.jar}} is in both contrib/extraction and contrib/analysis-extra
(11Mb!)
{{solr-core*.jar}} (4,3Mb) is one of many both in WEB-INF/lib and dist. Could
we write a script {{prep-dist}} that copies dupes from wherever into dist?
> 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6806) Reduce the size of the main Solr binary download
[ https://issues.apache.org/jira/browse/SOLR-6806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15882673#comment-15882673 ] Jan Høydahl commented on SOLR-6806: --- Good point, if you need it you can always download the src and build it, since you're obviously doing some kind of development, right? Do you want to create a sub-task for it? > 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6806) Reduce the size of the main Solr binary download
[ https://issues.apache.org/jira/browse/SOLR-6806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15882655#comment-15882655 ] Alexandre Rafalovitch commented on SOLR-6806: - dist/test-framework is still there. I still don't think we need it. That's 10Mb. > 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6806) Reduce the size of the main Solr binary download
[ https://issues.apache.org/jira/browse/SOLR-6806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15880269#comment-15880269 ] Jan Høydahl commented on SOLR-6806: --- Now that SOLR-4950 is getting resolved, what is the next baby step in reducing the Solr download size? > 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6806) Reduce the size of the main Solr binary download
[ https://issues.apache.org/jira/browse/SOLR-6806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15445507#comment-15445507 ] Jan Høydahl commented on SOLR-6806: --- Opened sub task SOLR-9450 for this > 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.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6806) Reduce the size of the main Solr binary download
[ https://issues.apache.org/jira/browse/SOLR-6806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15443601#comment-15443601 ] Shawn Heisey commented on SOLR-6806: In general, I like the idea of just providing a reference to the online copy. The percentage of users that download Solr and use it in an offline system would be *VERY* small, perhaps statistically insignificant ... and as you say, downloading the source code (which is much smaller than the binary) would give them the ability to generate the docs locally. I've mostly been thinking about Solr here. Because Lucene users are developers who have a decent chance of writing code in places with no connectivity (like airplanes), I do think that Lucene must include its docs in the binary archive, and for that, it should probably be an inner archive, to avoid initial extraction of thousands of tiny files. I do think that placing licenses into an inner archive should happen for both Lucene and Solr. It will slightly complicate the build system, because the zip needs a zip and the tgz needs a tgz. Can't see any reason to change how these things work in the source code. > 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.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6806) Reduce the size of the main Solr binary download
[ https://issues.apache.org/jira/browse/SOLR-6806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15442275#comment-15442275 ] Jan Høydahl commented on SOLR-6806: --- Let's replace the contents of the docs folder with one single file index.html, which contains just one link to the online docs (e.g.) http://lucene.apache.org/solr/6_2_0/index.html On that online docs page we could alternatively provide a download link to download the docs offline. We don't need to formally release a docs archive? It is all in the src download anyway. > 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.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6806) Reduce the size of the main Solr binary download
[ https://issues.apache.org/jira/browse/SOLR-6806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15441878#comment-15441878 ] Shawn Heisey commented on SOLR-6806: A potential baby step is to do something different with docs. I see two good options: * Remove the docs from the main download entirely, create a separate downloadable archive for them. For 6.2, this archive would be about 13MB, making the main download nearly 10 percent lighter. * Put the compressed docs archive in the main archive. This wouldn't reduce the size of the download, but it *WOULD* make the archive extract a LOT faster. See screenshots that I attached earlier. I think it's a good idea to do the second option to the licenses directory. This directory doesn't have as many small files in it as the docs directory, but it still has a significant impact on main archive extraction speed. These files need to be in the main archive, but IMHO it's perfectly acceptable to have them contained in an inner 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 > 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.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6806) Reduce the size of the main Solr binary download
[
https://issues.apache.org/jira/browse/SOLR-6806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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
[jira] [Commented] (SOLR-6806) Reduce the size of the main Solr binary download
[ https://issues.apache.org/jira/browse/SOLR-6806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15203355#comment-15203355 ] Shawn Heisey commented on SOLR-6806: Side proposal, which I'm willing to forget about: Consider putting the main DIH jar back into WEB-INF/lib, and possibly even moving its code into core. The DIH-extras code and jars probably still belong in contrib. I think that for a lot of users, DIH was the primary reason that they seriously investigated Solr. I know it was a primary consideration when I first started. For users like that, DIH is not "extra" functionality, it's part of their core usage. The main DIH jar is also very small, slightly larger than 200KB. > 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
[jira] [Commented] (SOLR-6806) Reduce the size of the main Solr binary download
[ https://issues.apache.org/jira/browse/SOLR-6806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15203353#comment-15203353 ] Shawn Heisey commented on SOLR-6806: One idea that would take care of most every concern created by splitting artifacts in the first place: Put *all* of the pieces that we extract from the main artifact (except docs, that gets its own) into a "solr-extras" artifact. It would be large, but there will be a lot less "if x then y" documentation required. > 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
[jira] [Commented] (SOLR-6806) Reduce the size of the main Solr binary download
[ https://issues.apache.org/jira/browse/SOLR-6806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15203106#comment-15203106 ] Shawn Heisey commented on SOLR-6806: 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
[jira] [Commented] (SOLR-6806) Reduce the size of the main Solr binary download
[ https://issues.apache.org/jira/browse/SOLR-6806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15203097#comment-15203097 ] Shawn Heisey commented on SOLR-6806: Ouch. That represents a fairly significant drop in the size of the contrib folder, and a small drop in the overall size of the artifacts that a release manager must upload. I actually would have suggested the one in analysis-extras as the one to keep. I use the ICU classes from Lucene, so it's logical for that to be the one I'd expect to be there. In the end, I don't really care which one is kept, as long as there's general consensus. I haven't got any clue about which of those contrib modules gets used more often. We could drop a symlink into one of those locations in the .tgz 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
[jira] [Commented] (SOLR-6806) Reduce the size of the main Solr binary download
[
https://issues.apache.org/jira/browse/SOLR-6806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15203043#comment-15203043
]
Alexandre Rafalovitch commented on SOLR-6806:
-
Another data point. We have two copies of the icu4j-54.1.jar library at 11Mb
each (in Solr 5.5). They are at:
{quote}
./contrib/analysis-extras/lib/icu4j-54.1.jar
./contrib/extraction/lib/icu4j-54.1.jar
{quote}
We probably only need one of them; I am guessing the one in the /extraction.
> 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
[jira] [Commented] (SOLR-6806) Reduce the size of the main Solr binary download
[ https://issues.apache.org/jira/browse/SOLR-6806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15203002#comment-15203002 ] Alexandre Rafalovitch commented on SOLR-6806: - Just as a data point. Javadocs are 5Mb extra in the download and ~70Mb when unpacked. And most of the classes they describe are not very useful for a non-developer. I'd cut that and make Javadoc much more accessible through the main website instead. > 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
[jira] [Commented] (SOLR-6806) Reduce the size of the main Solr binary download
[
https://issues.apache.org/jira/browse/SOLR-6806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14702845#comment-14702845
]
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 for
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: 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
[jira] [Commented] (SOLR-6806) Reduce the size of the main Solr binary download
[ https://issues.apache.org/jira/browse/SOLR-6806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14332264#comment-14332264 ] Alexandre Rafalovitch commented on SOLR-6806: - From the things that could be removed (I think): 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. 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
[jira] [Commented] (SOLR-6806) Reduce the size of the main Solr binary download
[ https://issues.apache.org/jira/browse/SOLR-6806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14332368#comment-14332368 ] Shawn Heisey commented on SOLR-6806: bq. Folks who care a lot about the num bytes they have to download should be encouraged to use the source releases and compile themselves This is somewhat deceptive in terms of what has to be downloaded. Let's say that a user starts with a clean system that already has all the required tools downloaded and installed - ant, the jdk, etc. The solr source download for 5.0.0 is 35MB, which is considerably smaller than the 128MB (zip) or 122 MB (tgz) binary download. So far so good, but you're not done getting large amounts of data from the Internet yet. Building the 5.0.0 server target will download 119MB into the ivy cache, so the total download required is larger than the binary. Additional builds will use the already downloaded cache, of course. Side note: I found it interesting that the Lucene core builds *before* any third-party libraries are downloaded. It's pretty awesome that the most important piece of the puzzle is written entirely with code native to the JDK. 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
[jira] [Commented] (SOLR-6806) Reduce the size of the main Solr binary download
[ https://issues.apache.org/jira/browse/SOLR-6806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14230784#comment-14230784 ] Hoss Man commented on SOLR-6806: My broad strokes opinion on being concerned with the release sizes is simple: * Folks who care a lot about the num bytes they have to download should be encouraged to use the source releases and compile themselves ** as much as possible we should make it dead simple to build solr from source for these people with poor net connections who are concerned about saving bytes. * the binary releases should strive for being as dead simple to use as possible, since their target user is a novice who doesn't (yet) know/understand what they need/want. ** if that means they are kind of big, because they include all contribs, that is (in my opinion) more new user friendly then having users discover after downloading installing solr that they have to go download and install 27 other micro plugins in order to get it to do what they want. as Doug once wisely pointed out... bq. The reason is that you don't optimize the out-of-box experience for advanced users: it's okay to frustrate them a bit, they're going to find what they need in the download. The more important thing is not to confuse newbies. A single download with documentation and examples is what newbies need. While you might be somewhat annoyed by the extra baggage, how much harder does it really make your life? 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
[jira] [Commented] (SOLR-6806) Reduce the size of the main Solr binary download
[ https://issues.apache.org/jira/browse/SOLR-6806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14230803#comment-14230803 ] Yonik Seeley commented on SOLR-6806: 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 (why try to maintain a different online and offline version?) A kitchen sink approach can also leave one with the impression of bloated, complicated, confusing. 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
[jira] [Commented] (SOLR-6806) Reduce the size of the main Solr binary download
[ https://issues.apache.org/jira/browse/SOLR-6806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14228819#comment-14228819 ] Shawn Heisey commented on SOLR-6806: A fix for this issue would probably *increase* the size of the binary artifacts that a release manager must upload, which is contrary to LUCENE-5589 goals ... but hopefully it would not increase it by very much. 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
[jira] [Commented] (SOLR-6806) Reduce the size of the main Solr binary download
[ https://issues.apache.org/jira/browse/SOLR-6806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14228824#comment-14228824 ] Shawn Heisey commented on SOLR-6806: One thing we could do for immediate relief is to only include the war in the dist directory, not the webapps directory. The bin/solr script that was recently added could copy the war from the dist directory to the webapps directory, if it's not already present. That would reduce the download by almost 30MB. 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
[jira] [Commented] (SOLR-6806) Reduce the size of the main Solr binary download
[ https://issues.apache.org/jira/browse/SOLR-6806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14228847#comment-14228847 ] Yonik Seeley commented on SOLR-6806: bq. One thing we could do for immediate relief is to only include the war in the dist directory, not the webapps directory. Seems like it should be vice-versa given that a war is no longer distributed? 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
[jira] [Commented] (SOLR-6806) Reduce the size of the main Solr binary download
[ https://issues.apache.org/jira/browse/SOLR-6806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14228900#comment-14228900 ] Ramkumar Aiyengar commented on SOLR-6806: - bq. Seems like it should be vice-versa given that a war is no longer distributed? I just uploaded a patch to do this in SOLR-4792. 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
[jira] [Commented] (SOLR-6806) Reduce the size of the main Solr binary download
[ https://issues.apache.org/jira/browse/SOLR-6806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14229021#comment-14229021 ] Shawn Heisey commented on SOLR-6806: bq. Seems like it should be vice-versa given that a war is no longer distributed? It's all making my head spin. :) I don't know where things are going to land. 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
