I knew it wasn't me! :) I found the patch just before I read this and applied it to the trunk and it works!
Thanks Mark and martijn for all your help! - Moazzam On Thu, Jun 17, 2010 at 2:16 PM, Martijn v Groningen <martijn.is.h...@gmail.com> wrote: > 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 >
