> > 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 Heisey <apa...@elyograg.org> wrote: > 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 > >
