Re: Splitting Solr artifacts so the main download is smaller
> > A tangent to think about later: RPM and DEB packaging. That's a lot to > discuss, so I won't go into it here. Even though you didn't want to get into it here, I did create a Solr RPM/DEB builder here: https://github.com/sdavids13/solr-os-packager Sure would be pretty sweet to get an official RPM distribution, I think that would make a lot of admin's lives easier (primarily for upgrades). -Steve On Mon, Apr 4, 2016 at 6:56 PM, Shawn Heiseywrote: > On 4/4/2016 12:57 PM, Jan Høydahl wrote: > > A difference from ES is that they have a working plugin ecosystem, so > > you can tell users to run "bin/plugin install kuromoji” or whatever. > > Could we not continue working on SOLR-5103, and the size issue will > > solve itself in a much more elegant way... > > Sure. I love the idea of a plugin system that can reach out and install > functionality from the Internet. Would that need something new from > Infra? That's something we can hammer out on the Jira issue. > > I think step one for SOLR-5103 is to split the artifacts in a manner > similar to what I outlined in SOLR-6806. Then the other artifacts can > be further diced up into small pieces that can be handled by a plugin > system. We don't necessarily need to do these separately, though -- > SOLR-5103 could absorb and replace SOLR-6806. > > A tangent to think about later: RPM and DEB packaging. That's a lot to > discuss, so I won't go into it here. > > Thanks, > Shawn > > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > >
Re: Splitting Solr artifacts so the main download is smaller
On 4/4/2016 12:57 PM, Jan Høydahl wrote: > A difference from ES is that they have a working plugin ecosystem, so > you can tell users to run "bin/plugin install kuromoji” or whatever. > Could we not continue working on SOLR-5103, and the size issue will > solve itself in a much more elegant way... Sure. I love the idea of a plugin system that can reach out and install functionality from the Internet. Would that need something new from Infra? That's something we can hammer out on the Jira issue. I think step one for SOLR-5103 is to split the artifacts in a manner similar to what I outlined in SOLR-6806. Then the other artifacts can be further diced up into small pieces that can be handled by a plugin system. We don't necessarily need to do these separately, though -- SOLR-5103 could absorb and replace SOLR-6806. A tangent to think about later: RPM and DEB packaging. That's a lot to discuss, so I won't go into it here. Thanks, Shawn - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Splitting Solr artifacts so the main download is smaller
A difference from ES is that they have a working plugin ecosystem, so you can tell users to run "bin/plugin install kuromoji” or whatever. Could we not continue working on SOLR-5103, and the size issue will solve itself in a much more elegant way... -- Jan Høydahl, search solution architect Cominvent AS - www.cominvent.com > 19. mar. 2016 kl. 19.15 skrev Shawn Heisey: > > I'd like to see some motion on this, which probably means I need to do > it myself. I'd like to know who I can talk to about the build/packaging > system so I can find what needs to change, and especially so I don't > break it. > > There's already a jira issue -- SOLR-6806, with some related bits in > SOLR-5103. > > The Solr download for 5.5.0 is 130 or 138 megabytes, depending on what > OS you're going to install it on. For the rest of this email, let's > focus on the .zip version (138MB), since my client is Windows and I'd > like to compare apples to apples. > > We have a .zip download size of 138MB, which thankfully is down in size > since we completely dropped the war file. That *other* search engine > based on Lucene has a .zip download size of 28MB. > > I started fiddling with the download archive on my Windows machine, > pulling out obvious pieces at the root of the extracted archive, and > managed to get the .zip size down to 40MB. > > If I dig further and remove the lucene-analyzers-kuromoji jar (over 4MB) > and the hadoop jars (10MB), which the majority of Solr's users will > *never* need, Solr 5.5's .zip file drops to 25MB. > > I'm not suggesting that we just remove these pieces. We would need to > have a main artifact and several supporting artifacts. The total size > would be virtually the same, so the concerns in LUCENE-5589 and > LUCENE-6247 will not get worse. They also won't get better. > > There's plenty of opportunity for bikeshedding here, but that should be > done in Jira. For this email, I'd like to know if anyone has strong > opposition to this, and if not, who would be willing to provide guidance > for how to do it right. > > Thanks, > Shawn > > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Splitting Solr artifacts so the main download is smaller
Apparently no strong opinions against; so go for it! On Sat, Mar 19, 2016 at 2:14 PM Shawn Heiseywrote: > I'd like to see some motion on this, which probably means I need to do > it myself. I'd like to know who I can talk to about the build/packaging > system so I can find what needs to change, and especially so I don't > break it. > > There's already a jira issue -- SOLR-6806, with some related bits in > SOLR-5103. > > The Solr download for 5.5.0 is 130 or 138 megabytes, depending on what > OS you're going to install it on. For the rest of this email, let's > focus on the .zip version (138MB), since my client is Windows and I'd > like to compare apples to apples. > > We have a .zip download size of 138MB, which thankfully is down in size > since we completely dropped the war file. That *other* search engine > based on Lucene has a .zip download size of 28MB. > > I started fiddling with the download archive on my Windows machine, > pulling out obvious pieces at the root of the extracted archive, and > managed to get the .zip size down to 40MB. > > If I dig further and remove the lucene-analyzers-kuromoji jar (over 4MB) > and the hadoop jars (10MB), which the majority of Solr's users will > *never* need, Solr 5.5's .zip file drops to 25MB. > > I'm not suggesting that we just remove these pieces. We would need to > have a main artifact and several supporting artifacts. The total size > would be virtually the same, so the concerns in LUCENE-5589 and > LUCENE-6247 will not get worse. They also won't get better. > > There's plenty of opportunity for bikeshedding here, but that should be > done in Jira. For this email, I'd like to know if anyone has strong > opposition to this, and if not, who would be willing to provide guidance > for how to do it right. > > Thanks, > Shawn > > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > > -- Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker LinkedIn: http://linkedin.com/in/davidwsmiley | Book: http://www.solrenterprisesearchserver.com