lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexandre Rafalovitch <arafa...@gmail.com>
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 <solr@elyograg.org> 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:
http://mvnrepository.com/artifact/org.apache.solr
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:
http://blog.outerthoughts.com/2013/07/setting-up-apache-solr-on-windows-as-a-service/


Regards,
   Alex.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message