Hi Moazzam,
Where did u get the src code from??
I am downloading it from
https://svn.apache.org/repos/asf/lucene/solr/branches/branch-1.4
and the latest revision in this location is 955469.
so applying the latest patch(dated 17th june 2010) on it still generates
errors.
Any Pointers?
Regards,
Raakhi
On Fri, Jun 18, 2010 at 1:24 AM, Moazzam Khan <moazz...@gmail.com> wrote:
> 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
> >
>
