lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexandre Rafalovitch <>
Subject Re: Request for discussion: Solr plugins
Date Thu, 29 May 2014 07:17:24 GMT
On Thu, May 29, 2014 at 1:17 PM, Shawn Heisey <> wrote:
> On 5/28/2014 10:01 PM, Alexandre Rafalovitch wrote:

>> 5) Solr, frankly, is getting rather pudgy. Or possibly beyond mere
>> pudgy. This is becoming especially noticeable by comparison with
>> ElasticSearch but also with the increasing frequency of releases. I
>> mentioned this issue a couple of times in the past under different
>> angles (bundling Javadoc, compressing files, easy onboarding, etc).
> One of our PMC members has filed an issue regarding the extreme size of
> the Lucene/Solr artifacts that have to be lugged around to do a release.
>  This issue is LUCENE-5589.  That is a different (but related) topic to
> what you are talking about, which is the pieces that a user must download.
Agree, it's quite a different but related topic.

> To address the size problem on the user side, we need a "core" package
> that only includes what is needed to get a basic Solr started.  I
> wouldn't mind at all if *none* of the contrib modules are included.
> Exactly how to organize the module downloads is something I'm not sure
> about, but I do think that DIH and SolrJ should be available in their
> own downloads separate from the rest, because those downloads would be
> pretty small.
It's sort of happening as maven modules:
But I am not sure anybody is really consuming those (apart from maybe
Spring project and SolrJ users), so it may not be really correct. But
the release pipeline seems to be there.

> If Apache's distribution rules will allow it, I think that Javadocs
> should also be a separate download.
Agree. That's quite a bit of weight. Though shipping them compressed
(and keeping them compressed) is a smaller next step.

> A plugin infrastructure that allows a user to start Solr and then click
> to install a plugin would be, quite frankly, beyond awesome.
Exactly. That's the point here.

> If it can be managed effectively, it would also be nice to have a
> third-party plugin repository, like Mozilla and Wordpress.
I am offering to have a first go at this one, if Solr supports the
actual mechanism.

>> I would especially love to see a discussion of the lowest hanging
>> fruit. Even if we cannot decompose Solr itself right now, maybe we can
>> introduce additional package handling mechanism and then retrofit Solr
>> into that.
> Let's figure out what the lowest hanging fruit is and get the work
> started!  I'd like to help too.
Great. Anybody else in with specific ideas/angles?

> On a tangent:
> Part of the "out of box" experience that's missing is installation
> scripts, which until we come up with something new for 5.0, would be for
> the example jetty.  I have an init script that works very well, but only
> on Redhat-derived Linux distributions.  It requires a lot of manual work
> to get started, and automating that would be a huge plus for users.
That goes to a separate discussion I think about devops-y aspects.
There is, again, a number of community install/build scripts but
nobody is looking at them and distilling them into best practice.
I suspect the easiest next step could be to piggy back onto something
like docker and release Solr as a docker box into all the services
that support it.
Then, work on the rest of the methods.

> My init script needs to be extended to cover Debian-derived
> distributions at the very minimum.  Support for Solaris and other
> popular UNIX variants would be useful.  As much as I don't like the
> platform for anything but client systems, if we can come up with a way
> to install on Windows as a service, we will truly open Solr up to the
> masses.
Agreed. My article on Windows install seem to be hitting quite a nerve
based on Google analytics:


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message