Oops this is probably i didn't checkout the modules file from the trunk. doing that right now :)
Regards Raakhi On Wed, Jun 23, 2010 at 1:12 PM, Rakhi Khatwani <[email protected]> wrote: > 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 < > [email protected]> wrote: > >> What exactly did not work? Patching, compiling or running it? >> >> On 22 June 2010 16:06, Rakhi Khatwani <[email protected]> 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 < >> > [email protected]> 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 <[email protected]> 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 < >> >> > [email protected]> 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 <[email protected]> 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 <[email protected] >> > >> >> >> 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 >> >> >> >> <[email protected]> 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 <[email protected]> >> >> 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 >> > >
