Hi, Patching did work. but when i build the trunk, i get the following exception:
[SolrTrunk]# ant compile Buildfile: /testWorkspace/SolrTrunk/build.xml init-forrest-entities: [mkdir] Created dir: /testWorkspace/SolrTrunk/build [mkdir] Created dir: /testWorkspace/SolrTrunk/build/web compile-lucene: BUILD FAILED /testWorkspace/SolrTrunk/common-build.xml:207: /testWorkspace/modules/analysis/common does not exist. Regards, Raakhi On Wed, Jun 23, 2010 at 2:39 AM, Martijn v Groningen < martijn.is.h...@gmail.com> wrote: > What exactly did not work? Patching, compiling or running it? > > On 22 June 2010 16:06, Rakhi Khatwani <rkhatw...@gmail.com> wrote: > > Hi, > > I tried checking out the latest code (rev 956715) the patch did not > > work on it. > > Infact i even tried hunting for the revision mentioned earlier in this > > thread (i.e. rev 955615) but cannot find it in the repository. (it has > > revision 955569 followed by revision 955785). > > > > Any pointers?? > > Regards > > Raakhi > > > > On Tue, Jun 22, 2010 at 2:03 AM, Martijn v Groningen < > > martijn.is.h...@gmail.com> wrote: > > > >> Oh in that case is the code stable enough to use it for production? > >> - Well this feature is a patch and I think that says it all. > >> Although bugs are fixed it is deferentially an experimental feature > >> and people should keep that in mind when using one of the patches. > >> Does it support features which solr 1.4 normally supports? > >> - As far as I know yes. > >> > >> am using facets as a workaround but then i am not able to sort on any > >> other field. is there any workaround to support this feature?? > >> - Maybee http://wiki.apache.org/solr/Deduplication prevents from > >> adding duplicates in you index, but then you miss the collapse counts > >> and other computed values > >> > >> On 21 June 2010 09:04, Rakhi Khatwani <rkhatw...@gmail.com> wrote: > >> > Hi, > >> > Oh in that case is the code stable enough to use it for production? > >> > Does it support features which solr 1.4 normally supports? > >> > > >> > I am using facets as a workaround but then i am not able to sort on > any > >> > other field. is there any workaround to support this feature?? > >> > > >> > Regards, > >> > Raakhi > >> > > >> > On Fri, Jun 18, 2010 at 6:14 PM, Martijn v Groningen < > >> > martijn.is.h...@gmail.com> wrote: > >> > > >> >> Hi Rakhi, > >> >> > >> >> The patch is not compatible with 1.4. If you want to work with the > >> >> trunk. I'll need to get the src from > >> >> https://svn.apache.org/repos/asf/lucene/dev/trunk/ > >> >> > >> >> Martijn > >> >> > >> >> On 18 June 2010 13:46, Rakhi Khatwani <rkhatw...@gmail.com> wrote: > >> >> > 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 > >> >> >> > > >> >> >> > >> >> > > >> >> > >> > > >> > >> > >> > >> -- > >> Met vriendelijke groet, > >> > >> Martijn van Groningen > >> > > > > > > -- > Met vriendelijke groet, > > Martijn van Groningen >