Erik Hatcher wrote:
On Feb 25, 2006, at 3:24 PM, Daniel Naber wrote:
On Freitag 24 Februar 2006 00:50, Doug Cutting wrote:
Are these all modules that don't need external libs?
So far as I know!
I found another module that requires external libraries: regex. These
are
even defined in th
On Feb 26, 2006, at 7:18 AM, Daniel Naber wrote:
On Sonntag 26 Februar 2006 02:42, Erik Hatcher wrote:
I personally don't think we should be distributing any external
dependencies. Whoever builds the releases needs to have the
dependencies locally, but 3rd party JARs, even Apache ones, should
On Sonntag 26 Februar 2006 02:42, Erik Hatcher wrote:
> I personally don't think we should be distributing any external
> dependencies. Whoever builds the releases needs to have the
> dependencies locally, but 3rd party JARs, even Apache ones, should
> not go along for the .tar/zip ride IMO
On Feb 25, 2006, at 3:24 PM, Daniel Naber wrote:
On Freitag 24 Februar 2006 00:50, Doug Cutting wrote:
Are these all modules that don't need external libs?
So far as I know!
I found another module that requires external libraries: regex.
These are
even defined in the additional.dependenc
Thanks Paul, it's in.
Otis
- Original Message
From: Paul Elschot <[EMAIL PROTECTED]>
To: java-dev@lucene.apache.org
Sent: Saturday, February 25, 2006 7:09:25 AM
Subject: Re: Lucene 1.9 RC1 release available: surround package.html files
On Saturday 25 February 2006 01:23, Chri
On Freitag 24 Februar 2006 00:50, Doug Cutting wrote:
> > Are these all modules that don't need external libs?
>
> So far as I know!
I found another module that requires external libraries: regex. These are
even defined in the additional.dependencies property in the build.xml, but
it seems it's
On Saturday 25 February 2006 01:23, Chris Hostetter wrote:
>
...
>
> ...Which means this weekend would be a good time for contrib module owners
> to commit a quick one sentence "package.html" for each package in their
> module. Now that the contrib classes are built/bundled/distributed along
> w
: FYI, I think all of the commits to trunk since the RC1 release are safe
: to merge to the 1.9 branch. They're mostly documentation improvements.
: So my plan is currently, on Monday, to merge these changes to the 1.9
: branch, then make a 1.9-final release. I'll again announce it to the
...
On Freitag 24 Februar 2006 00:50, Doug Cutting wrote:
> > Are these all modules that don't need external libs?
>
> So far as I know! They built without me downloading anything extra.
Lucli requires jline.jar which is also in SVN and can be distributed thanks
to its very liberal license (jline.L
On Feb 23, 2006, at 6:33 PM, Daniel Naber wrote:
BTW, lucli (the command line lucene searcher) builds fine, but the
manifest
in the jar doesn't specify the Main-Class so you cannot start it with
java's -jar option. Could someone have a look at this (Erik?)? I don't
understand how that ant task
Daniel Naber wrote:
Are these all modules that don't need external libs?
So far as I know! They built without me downloading anything extra.
FYI, I think all of the commits to trunk since the RC1 release are safe
to merge to the 1.9 branch. They're mostly documentation improvements.
So my
On Freitag 24 Februar 2006 00:33, Daniel Naber wrote:
> Shouldn't we include at least some package from contrib, like analyzers
> and highlighter?
Sorry, I totally missed the "contrib" sub directory that contains
everything I'm asking for... Are these all modules that don't need
external libs?
On Dienstag 21 Februar 2006 18:50, Doug Cutting wrote:
> I will send this announcement to user list tomorrow if no major issues
> are identified. If things still look good next week, I will promote
> this release to 1.9-final.
Shouldn't we include at least some package from contrib, like analyze
Arguing about this won't change the code. A well-constructed patch
might (but there are no guarantees).
To me, this sounds like an uphill battle. If we want to add a feature
to wildcard 0-N characters at the end of a word, then I don't think we'd
use '?' plus a flag. Rather I think it would
Grant Ingersoll wrote:
I am wondering what the motivation is for being forward compatible to
2.0. Is the only change from 1.9 to 2.0 going to be the removal of
deprecated items?
Pretty much, yes.
Are we going to be preventing ourselves from making
broader structural changes? My understand
Doug Cutting wrote:
1.9 will be the last 1.x release. It is both back-compatible with
1.4.3 and forward-compatible with the upcoming 2.0 release. Many
methods and classes in 1.4.3 have been deprecated in 1.9 and will be
removed in 2.0. Applications must compile against 1.9 without
deprecati
1) Having a simple way to match singular and plural forms of a term with
a single wildcard expression is quite useful.
2) The trailing '?' behavior has been present since that wildcard was
first introduced. Why not provide a flag to allow the original behavior
to optionally be preserved?
3) The
: In either case, what I'm arguing is that the current behavior makes more
: sense in the real world of query expressions (that is, makes the most
: common query expressions simpler), so why not continue it?
I disagree with that statment. People familiar with shell globing are
going to be confus
Hoss,
Whether the previous behavior (which I believe has been present in
Lucene from the outset) was a "bug" or a "feature" is kind of academic.
My point is that this behavior has value that's not countered by any
argument that any significant value is added by eliminating it.
As to your ri
Marvin,
While a stemming analyzer can work well for general purpose queries, if
you're seeking a decent level of precision/recall, stemming often
severely limits you. Moreover, unless the user is very familiar with
the behavior of the stemmer used, some of the returned results can be
quite s
: of query). Under the previous versions of QueryParser, I could simply
: specify 'riot???' and capture all of those variants.
I don't have a strong opinion on this issue, but it seems clear to me that
this was a bug in 1.4.3 not a change in the orriginally intended behavior.
queryparsersyntax.h
Terry,
Is there a reason you wouldn't use a stemming analyzer of some kind,
which would match cat and cats but not cater, catches, etc?
http://snowball.tartarus.org/demo.php
Marvin Humphrey
Rectangular Research
http://www.rectangular.com/
On Feb 21, 2006, at 3:13 PM, Terry Steichen wrote:
Terry,
I think most of the examples you provide are normally handled via stemming.
Using wildcarding for stemming will normally be less accurate.
The current behavior is also consistent with the way file globbing works.
-Yonik
On 2/21/06, Terry Steichen <[EMAIL PROTECTED]> wrote:
> Yonik,
>
>
Yonik,
No, I don't think that the riot* option would work for many queries.
Let's take a simple case where you want a singular or plural form, like
either cat or cats (which would be very common). With 1.4.x, you can
use cat? to retrieve such matches. With the new change, you need to use
(
On 2/21/06, Terry Steichen <[EMAIL PROTECTED]> wrote:
> For example, let's say that I'm interested in docs with terms 'riot',
> 'riots', 'rioting' and 'rioters' (which, I think, is a reasonable kind
> of query). Under the previous versions of QueryParser, I could simply
> specify 'riot???' and cap
In reviewing the latest changes incorporated into release 1.9 RC1, I
noticed a change responding to JIRA item LUCENE-306. According to the
writeup, the new change forces the wildcard pattern 'cat??' to exactly
match the length of the term (in this case, a five-letter term starting
with 'cat').
Doug Cutting wrote:
Release 1.9 RC1 of Lucene is now available from:
http://www.apache.org/dyn/closer.cgi/lucene/java/
I will send this announcement to user list tomorrow if no major issues
are identified. If things still look good next week, I will promote
this release to 1.9-final. Once
Release 1.9 RC1 of Lucene is now available from:
http://www.apache.org/dyn/closer.cgi/lucene/java/
This release candidate has many improvements since release 1.4.3,
including new features, performance improvements, bug fixes, etc. For
details, see:
http://svn.apache.org/viewcvs.cgi/*checkou
28 matches
Mail list logo
