Hi, I would like to (re-)initiate a discussion about Solr support for plugin life-cycle (publish, discover, download, dependency management). Triggered by a discussion on the Solr mailing list: http://search-lucene.com/m/QTPaIv50e1&subj=Re+Contribute+QParserPlugin
My main points: 1) Plugins/Modules/packages seem to be a very core part of most of the modern projects 2) Solr is extremely modular on the implementation level. 3) The community has been slowly building various plugins for Solr, but without any way to announce/share them. 4) ElasticSearch has plugins and it's been consistently pointed out as a positive point (good on them) 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). 6) Solr has so many features now that nobody will explore them all; yet people still download them and - sometimes - get confused by all the directories, jars and locations. Polish support alone has a significant number of jars (not sure about file sizes). I am not even talking about map-reduce+morphline in the recent release. 7) Solr is already published as a set of Maven jars with dependencies expressed between components. 8) Apart from making initial downloads smaller, having proper module system (publish, discover, download, install) provides incentives for people to push the packages out, creates a stronger community Now, I know that some of the weight might be addressed in Solr 5 by not bundling the war file as well as the libs. And some of the ElasticSearch comparison is due to the different philosophical approach (kitchen sink vs not even bundling Admin UI). And that any individual person does not download Solr packages that often (I might be an exception). But I still think we need the discussion. 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. In terms of skin-in-the-game, I would be happy to build and operate package publish/discovery system/website if Solr was actually able to support one. :-) Regards, Alex. Personal website: http://www.outerthoughts.com/ Current project: http://www.solr-start.com/ - Accelerating your Solr proficiency --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
