lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rakhi Khatwani <rkhatw...@gmail.com>
Subject Re: Field Collapsing SOLR-236
Date Wed, 23 Jun 2010 07:42:28 GMT
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.hier@gmail.com> wrote:

> What exactly did not work? Patching, compiling or running it?
>
> On 22 June 2010 16:06, Rakhi Khatwani <rkhatwani@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.hier@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 <rkhatwani@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.hier@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 <rkhatwani@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 <moazzamk@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.hier@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.hatcher@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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message