On Thu, May 29, 2014 at 1:17 PM, Shawn Heisey <[email protected]> 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: [email protected] For additional commands, e-mail: [email protected]
