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

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...

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

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 Heisey wrote: > 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

Splitting Solr artifacts so the main download is smaller

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