You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by Doug Cutting <cu...@lucene.com> on 2003/01/16 19:25:48 UTC
time for 1.3 release?
There have been quite a few useful additions and fixes made to Lucene
since the 1.2 release. This might be a good time to start making a 1.3
release. What do other folks think?
I'd rather not go through the hassle of branching development, so this
would mean that we should avoid non-bug-fix changes while we're in the
'Release Candidate' phase, but hopefully that won't last long. If
someone feels strongly that we should branch, then they should also be a
Lucene developer willing to manage the branching, merging, etc. before
they speak up.
If folks agree that this is a good time, then the first step is to make
an RC1 release from the current sources. Peter Carlson ran the last
release process. Peter, would you like to run this one too?
The Lucene release process of record is described in:
http://nagoya.apache.org/eyebrowse/ReadMsg?listName=lucene-dev@jakarta.apache.org&msgNo=1233
Thoughts? Volunteers?
Doug
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: time for 1.3 release?
Posted by Phil Shaw <ph...@codestyle.org>.
On 17 Jan 2003, at 10:15, Peter Carlson wrote:
> Let's do it.
>
> I'll be the lead on the RC. I will start working on it this weekend.
Peter,
This is my first week on the lucene-dev list but this may be a good
way to get familiar with the project. I could do some low level stuff
to help out, check or perhaps draft an Ant build?
Best regards,
Phil
--
<url http://www.codestyle.org/>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: time for 1.3 release?
Posted by Peter Mularien <pm...@deploy.com>.
I heartily agree. I can help with any important bug fixes that we feel
should go into the release. Also releasing an RC will get the newer code
into the hands of more people and would likely find additional bugs.
Peter
Doug Cutting wrote:
> There have been quite a few useful additions and fixes made to Lucene
> since the 1.2 release. This might be a good time to start making a
> 1.3 release. What do other folks think?
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: RE : java.lang.UnsupportedOperationException
Posted by Doug Cutting <cu...@lucene.com>.
Thanks for the test case. I just checked in a fix for this problem.
Doug
Rasik Pandey wrote:
> Doug,
> It is a attached. I added a WildCardQuery to the TestWildcard class with
> the Term text being "m*a*", it executes fine as a WildCardQuery, but
> when I wrap it in a BooleanQuery, I get the exception I sent previously.
> Let me know if I should enter a bug report?
>
> Thanks,
> Rasik
>
> -----Message d'origine-----
> De : Doug Cutting [mailto:cutting@lucene.com]
> Envoyé : vendredi 17 janvier 2003 20:47
> À : Lucene Developers List
> Objet : Re: java.lang.UnsupportedOperationException
>
>
> Sounds like a bug.
>
> Can you please supply a complete, self-contained test case? Ideally as
> a JUnit test class.
>
> Thanks,
>
> Doug
>
> Rasik Pandey wrote:
>
>>Hello,
>>
>>Can anyone explain we I would be seeing this when re-using a query
>>(MultiTermQuery or PrefixQuery, or any Query that doesn't implement
>>the new createWeight() method) object? The first search with this
>>query works fine.
>>
>>
>>java.lang.UnsupportedOperationException
>> at org.apache.lucene.search.Query.createWeight(Query.java:114)
>> at
>>org.apache.lucene.search.BooleanQuery.createWeight(BooleanQuery.java:2
>>02
>>)
>> at org.apache.lucene.search.Query.weight(Query.java:121)
>> at
>>org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:125)
>> at
>>org.apache.lucene.search.MultiSearcher.search(MultiSearcher.java:153)
>> at org.apache.lucene.search.Hits.getMoreDocs(Hits.java:91)
>> at org.apache.lucene.search.Hits.<init>(Hits.java:81)
>> at org.apache.lucene.search.Searcher.search(Searcher.java:74)
>> at org.apache.lucene.search.Searcher.search(Searcher.java:68)
>>
>>
>>Thanks,
>>Rasik
>>
>>
>>--
>>To unsubscribe, e-mail:
>
> <ma...@jakarta.apache.org>
>
>>For additional commands, e-mail:
>><ma...@jakarta.apache.org>
>>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <mailto:lucene-dev-help@jakarta.apache.org
>
>>
>>------------------------------------------------------------------------
>>
>>--
>>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>>For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE : java.lang.UnsupportedOperationException
Posted by Rasik Pandey <ra...@ajlsm.com>.
Doug,
It is a attached. I added a WildCardQuery to the TestWildcard class with
the Term text being "m*a*", it executes fine as a WildCardQuery, but
when I wrap it in a BooleanQuery, I get the exception I sent previously.
Let me know if I should enter a bug report?
Thanks,
Rasik
-----Message d'origine-----
De : Doug Cutting [mailto:cutting@lucene.com]
Envoyé : vendredi 17 janvier 2003 20:47
À : Lucene Developers List
Objet : Re: java.lang.UnsupportedOperationException
Sounds like a bug.
Can you please supply a complete, self-contained test case? Ideally as
a JUnit test class.
Thanks,
Doug
Rasik Pandey wrote:
> Hello,
>
> Can anyone explain we I would be seeing this when re-using a query
> (MultiTermQuery or PrefixQuery, or any Query that doesn't implement
> the new createWeight() method) object? The first search with this
> query works fine.
>
>
> java.lang.UnsupportedOperationException
> at org.apache.lucene.search.Query.createWeight(Query.java:114)
> at
> org.apache.lucene.search.BooleanQuery.createWeight(BooleanQuery.java:2
> 02
> )
> at org.apache.lucene.search.Query.weight(Query.java:121)
> at
> org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:125)
> at
> org.apache.lucene.search.MultiSearcher.search(MultiSearcher.java:153)
> at org.apache.lucene.search.Hits.getMoreDocs(Hits.java:91)
> at org.apache.lucene.search.Hits.<init>(Hits.java:81)
> at org.apache.lucene.search.Searcher.search(Searcher.java:74)
> at org.apache.lucene.search.Searcher.search(Searcher.java:68)
>
>
> Thanks,
> Rasik
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
Re: java.lang.UnsupportedOperationException
Posted by Doug Cutting <cu...@lucene.com>.
Sounds like a bug.
Can you please supply a complete, self-contained test case? Ideally as
a JUnit test class.
Thanks,
Doug
Rasik Pandey wrote:
> Hello,
>
> Can anyone explain we I would be seeing this when re-using a query
> (MultiTermQuery or PrefixQuery, or any Query that doesn't implement the
> new createWeight() method) object? The first search with this query
> works fine.
>
>
> java.lang.UnsupportedOperationException
> at org.apache.lucene.search.Query.createWeight(Query.java:114)
> at
> org.apache.lucene.search.BooleanQuery.createWeight(BooleanQuery.java:202
> )
> at org.apache.lucene.search.Query.weight(Query.java:121)
> at
> org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:125)
> at
> org.apache.lucene.search.MultiSearcher.search(MultiSearcher.java:153)
> at org.apache.lucene.search.Hits.getMoreDocs(Hits.java:91)
> at org.apache.lucene.search.Hits.<init>(Hits.java:81)
> at org.apache.lucene.search.Searcher.search(Searcher.java:74)
> at org.apache.lucene.search.Searcher.search(Searcher.java:68)
>
>
> Thanks,
> Rasik
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE : java.lang.UnsupportedOperationException
Posted by Rasik Pandey <ra...@ajlsm.com>.
Actually, I wrap my original query in a new BooleanQuery and then I get
this exception.
-----Message d'origine-----
De : Rasik Pandey [mailto:rasik.pandey@ajlsm.com]
Envoyé : vendredi 17 janvier 2003 17:29
À : 'Lucene Developers List'
Objet : java.lang.UnsupportedOperationException
Hello,
Can anyone explain we I would be seeing this when re-using a query
(MultiTermQuery or PrefixQuery, or any Query that doesn't implement the
new createWeight() method) object? The first search with this query
works fine.
java.lang.UnsupportedOperationException
at org.apache.lucene.search.Query.createWeight(Query.java:114)
at
org.apache.lucene.search.BooleanQuery.createWeight(BooleanQuery.java:202
)
at org.apache.lucene.search.Query.weight(Query.java:121)
at
org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:125)
at
org.apache.lucene.search.MultiSearcher.search(MultiSearcher.java:153)
at org.apache.lucene.search.Hits.getMoreDocs(Hits.java:91)
at org.apache.lucene.search.Hits.<init>(Hits.java:81)
at org.apache.lucene.search.Searcher.search(Searcher.java:74)
at org.apache.lucene.search.Searcher.search(Searcher.java:68)
Thanks,
Rasik
--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
java.lang.UnsupportedOperationException
Posted by Rasik Pandey <ra...@ajlsm.com>.
Hello,
Can anyone explain we I would be seeing this when re-using a query
(MultiTermQuery or PrefixQuery, or any Query that doesn't implement the
new createWeight() method) object? The first search with this query
works fine.
java.lang.UnsupportedOperationException
at org.apache.lucene.search.Query.createWeight(Query.java:114)
at
org.apache.lucene.search.BooleanQuery.createWeight(BooleanQuery.java:202
)
at org.apache.lucene.search.Query.weight(Query.java:121)
at
org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:125)
at
org.apache.lucene.search.MultiSearcher.search(MultiSearcher.java:153)
at org.apache.lucene.search.Hits.getMoreDocs(Hits.java:91)
at org.apache.lucene.search.Hits.<init>(Hits.java:81)
at org.apache.lucene.search.Searcher.search(Searcher.java:74)
at org.apache.lucene.search.Searcher.search(Searcher.java:68)
Thanks,
Rasik
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: time for 1.3 release?
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Doug Cutting wrote:
[...]
> The Lucene release process of record is described in:
>
> http://nagoya.apache.org/eyebrowse/ReadMsg?listName=lucene-dev@jakarta.apache.org&msgNo=1233
>
> Thoughts?
The release should now be done following the new mirroring rules.
http://www.apache.org/dev/mirrors.html
Here is a step by step description of how to do it:
http://cvs.apache.org/~bodewig/mirror.html
Cheers!
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: time for 1.3 release?
Posted by Otis Gospodnetic <ot...@yahoo.com>.
I was just looking at CHANGES.txt the other night and thought how it's
time for 1.3, so I'm for it. I think Peter is the only person besides
you with all the required accounts and priviledges.
Otis
--- Doug Cutting <cu...@lucene.com> wrote:
> There have been quite a few useful additions and fixes made to Lucene
>
> since the 1.2 release. This might be a good time to start making a
> 1.3
> release. What do other folks think?
>
> I'd rather not go through the hassle of branching development, so
> this
> would mean that we should avoid non-bug-fix changes while we're in
> the
> 'Release Candidate' phase, but hopefully that won't last long. If
> someone feels strongly that we should branch, then they should also
> be a
> Lucene developer willing to manage the branching, merging, etc.
> before
> they speak up.
>
> If folks agree that this is a good time, then the first step is to
> make
> an RC1 release from the current sources. Peter Carlson ran the last
> release process. Peter, would you like to run this one too?
>
> The Lucene release process of record is described in:
>
>
http://nagoya.apache.org/eyebrowse/ReadMsg?listName=lucene-dev@jakarta.apache.org&msgNo=1233
>
> Thoughts? Volunteers?
>
> Doug
__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: time for 1.3 release?
Posted by Alex Murzaku <li...@lissus.com>.
Yes. That's what I was proposing. And it's true - the stop word lists in
Snowball are quite good. I did offer wordlists for some languages that
weren't complete to Martin (Porter) - I don't know if they are included
or not. In any case, this was just to confirm their existence. In the
test cases I had built for my earlier Snowball-Lucene integration, I did
use these lists for the analyzers and also made sure to exclude them
from the tests (since the analyzer would remove them...)
Regards,
--
Alex Murzaku
___________________________________________
alex(at)lissus.com http://www.lissus.com
-----Original Message-----
From: Doug Cutting [mailto:cutting@lucene.com]
Sent: Friday, January 17, 2003 2:45 PM
To: Lucene Developers List
Subject: Re: time for 1.3 release?
I think you're proposing that the classes in
http://jakarta.apache.org/lucene/docs/lucene-sandbox/snowball/api/
be added to the core Lucene jar and release. Is that right?
I don't have a problem with this. Do others?
The Javadoc should probably also include a pointer to:
http://snowball.tartarus.org/
And I just noticed that Snowball has stop lists for most of the
languages too. It would be good for the analyzer to use these too, at
least as an option.
I can probably make these changes in the next week or so.
Doug
Alex Murzaku wrote:
> It would be nice to include the new Snowball interface as well. It
> surely could be better evaluated and used by the many people needing
> it. Sandbox is kind of hidden... Since the stemmers are very nicely
> isolated, I don't think they would interfere with testing the more
> radical scoring changes. Since scoring adds so much to Lucene, I would
> even think that this release is more closer to 2.0 :)
>
--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: time for 1.3 release?
Posted by Doug Cutting <cu...@lucene.com>.
I think you're proposing that the classes in
http://jakarta.apache.org/lucene/docs/lucene-sandbox/snowball/api/
be added to the core Lucene jar and release. Is that right?
I don't have a problem with this. Do others?
The Javadoc should probably also include a pointer to:
http://snowball.tartarus.org/
And I just noticed that Snowball has stop lists for most of the
languages too. It would be good for the analyzer to use these too, at
least as an option.
I can probably make these changes in the next week or so.
Doug
Alex Murzaku wrote:
> It would be nice to include the new Snowball interface as well. It
> surely could be better evaluated and used by the many people needing it.
> Sandbox is kind of hidden... Since the stemmers are very nicely
> isolated, I don't think they would interfere with testing the more
> radical scoring changes. Since scoring adds so much to Lucene, I would
> even think that this release is more closer to 2.0 :)
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: time for 1.3 release?
Posted by Alex Murzaku <li...@lissus.com>.
It would be nice to include the new Snowball interface as well. It
surely could be better evaluated and used by the many people needing it.
Sandbox is kind of hidden... Since the stemmers are very nicely
isolated, I don't think they would interfere with testing the more
radical scoring changes. Since scoring adds so much to Lucene, I would
even think that this release is more closer to 2.0 :)
--
Alex Murzaku
___________________________________________
alex(at)lissus.com http://www.lissus.com
-----Original Message-----
From: Doug Cutting [mailto:cutting@lucene.com]
Sent: Thursday, January 16, 2003 1:26 PM
To: Lucene Developers List
Subject: time for 1.3 release?
There have been quite a few useful additions and fixes made to Lucene
since the 1.2 release. This might be a good time to start making a 1.3
release. What do other folks think?
I'd rather not go through the hassle of branching development, so this
would mean that we should avoid non-bug-fix changes while we're in the
'Release Candidate' phase, but hopefully that won't last long. If
someone feels strongly that we should branch, then they should also be a
Lucene developer willing to manage the branching, merging, etc. before
they speak up.
If folks agree that this is a good time, then the first step is to make
an RC1 release from the current sources. Peter Carlson ran the last
release process. Peter, would you like to run this one too?
The Lucene release process of record is described in:
http://nagoya.apache.org/eyebrowse/ReadMsg?listName=lucene-dev@jakarta.a
pache.org&msgNo=1233
Thoughts? Volunteers?
Doug
--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: time for 1.3 release?
Posted by Peter Carlson <ca...@bookandhammer.com>.
Let's do it.
I'll be the lead on the RC. I will start working on it this weekend.
--Peter
On Thursday, January 16, 2003, at 10:25 AM, Doug Cutting wrote:
> There have been quite a few useful additions and fixes made to Lucene
> since the 1.2 release. This might be a good time to start making a
> 1.3 release. What do other folks think?
>
> I'd rather not go through the hassle of branching development, so this
> would mean that we should avoid non-bug-fix changes while we're in the
> 'Release Candidate' phase, but hopefully that won't last long. If
> someone feels strongly that we should branch, then they should also be
> a Lucene developer willing to manage the branching, merging, etc.
> before they speak up.
>
> If folks agree that this is a good time, then the first step is to
> make an RC1 release from the current sources. Peter Carlson ran the
> last release process. Peter, would you like to run this one too?
>
> The Lucene release process of record is described in:
>
> http://nagoya.apache.org/eyebrowse/ReadMsg?listName=lucene-
> dev@jakarta.apache.org&msgNo=1233
>
> Thoughts? Volunteers?
>
> Doug
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>