I've added a new patch to the issue, so building the trunk (rev 955615) with the latest patch should not be a problem. Due to recent changes in the Lucene trunk the patch was not compatible.
On 17 June 2010 20:20, Erik Hatcher <erik.hatc...@gmail.com> wrote: > > On Jun 16, 2010, at 7:31 PM, Mark Diggory wrote: >> >> p.s. I'd be glad to contribute our Maven build re-organization back to the >> community to get Solr properly Mavenized so that it can be distributed and >> released more often. For us the benefit of this structure is that we will >> be able to overlay addons such as RequestHandlers and other third party >> support without having to rebuild Solr from scratch. > > But you don't have to rebuild Solr from scratch to add a new request handler > or other plugins - simply compile your custom stuff into a JAR and put it in > <solr-home>/lib (or point to it with <lib> in solrconfig.xml). > >> Ideally, a Maven Archetype could be created that would allow one rapidly >> produce a Solr webapp and fire it up in Jetty in mere seconds. > > How's that any different than cd example; java -jar start.jar? Or do you > mean a Solr client webapp? > >> Finally, with projects such as Bobo, integration with Spring would make >> configuration more consistent and request significantly less java coding >> just to add new capabilities everytime someone authors a new RequestHandler. > > It's one line of config to add a new request handler. How many ridiculously > ugly confusing lines of Spring XML would it take? > >> The biggest thing I learned about Solr in my work thusfar is that patches >> like these could be standalone modules in separate projects if it weren't >> for having to hack the configuration and solrj methods up to adopt them. >> Which brings me to SolrJ, great API if it would stay generic and have less >> concern for adding method each time some custom collections and query >> support for morelikethis or collapseddocs needs to be added. > > I personally find it silly that we customize SolrJ for all these request > handlers anyway. You get a decent navigable data structure back from > general SolrJ query requests as it is, there's no need to build in all these > convenience methods specific to all the Solr componetry. Sure, it's > "convenient", but it's a maintenance headache and as you say, not generic. > > But hacking configuration is reasonable, I think, for adding in plugins. I > guess you're aiming for some kind of Spring-like auto-discovery of plugins? > Yeah, maybe, but I'm pretty -1 on Spring coming into Solr. It's overkill > and ugly, IMO. But you like it :) And that's cool by me, to each their > own. > > Oh, and Hi Mark! :) > > Erik > > -- Met vriendelijke groet, Martijn van Groningen
