Someone with the neccessary permisions to update the javadocs on the
website might want to do so, they currently say Lucene 1.9-rc1 API which
might confuse people (even if the API is exactly the same as 1.9.1)
http://lucene.apache.org/java/docs/api/
-Hoss
I just updated this. Thanks for catching it.
Doug
Chris Hostetter wrote:
Someone with the neccessary permisions to update the javadocs on the
website might want to do so, they currently say Lucene 1.9-rc1 API which
might confuse people (even if the API is exactly the same as 1.9.1)
http
Hi,
I have just updated to lucene 1.9, and hit a problem with the
mentioned optimization. I have applied it to the my
JdbcBufferedOutput (I only duplicate the code because the BUFFER_SIZE
is final), and I hit a problem. In the following code fragment (the
method is writeBytes):
...
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
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 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 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
with
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
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, Chris Hostetter
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
: 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: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?
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
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
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
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
Chris Hostetter wrote:
I think moving forward the query parser and fileformat docs should be
moved into docfile directories within the java source, so they are
reved/tagged with the individual releases. That way when people have
questions about the file format of their index built with 1.9 they
Maxim Patramanskij wrote:
Doug,
what about including optimization of BuffereIndexOutput.writeBytes()
method:
[ http://issues.apache.org/jira/browse/LUCENE-435?page=all ]
made by Lukas Zapletal, into 1.9?
I just committed this to trunk. If no issues arise with it there then
perhaps we can
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
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
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:
: 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.
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
: 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
Dan Armbrust [EMAIL PROTECTED] wrote on 17/02/2006 08:50:53
PM:
...
Short summary - The Constructor for IndexWriter currently will only
create an index in a folder if you set the boolean create flag to true.
But then, if you want to append to that index, you have to set the
create flag to
--- Nadav Har'El [EMAIL PROTECTED] wrote:
Dan Armbrust [EMAIL PROTECTED] wrote
on 17/02/2006 08:50:53
PM:
...
So I'm not sure the solution is to change the
semantics of the existing
constructor, but I think Lucene definitely need a
new constructor or
convenience
function that will do the
This week is pretty booked for me, so, barring major objections, I will
make a 1.9 RC1 release next Monday, February 20th. If there are no
problems discovered, I'll aim to make a 1.9 final release a week later,
around the 27th.
Has anyone tested if 1.9 can build with a Free Software
I'd like to see this improvement request implemented - but I'm not sure
if 1.9 or 2.0 would be a better place to do it:
http://issues.apache.org/jira/browse/LUCENE-301
Short summary - The Constructor for IndexWriter currently will only
create an index in a folder if you set the boolean create
I've been away from constant e-mail for several days (nice while it
lasted, but rough to come back to!)...
I'm +1 for 1.9 RC1, just for the record. As for the copyright years
- those should reflect only the years those files were touched, at
least that is how it is carefully done with Ant
Doug,
what about including optimization of BuffereIndexOutput.writeBytes()
method:
[ http://issues.apache.org/jira/browse/LUCENE-435?page=all ]
made by Lukas Zapletal, into 1.9?
I'm wondering, because this can decrease index creation time, which I
discovered as critical when using Lucene
On Feb 15, 2006, at 9:11 AM, DM Smith wrote:
Not to get to far ahead, but what is the schedule relation between
1.9 and 2.0?
What are the dependencies on releasing 2.0?
My understanding is that 2.0 will be 1.9 with all the deprecated API
removed. Maybe there are other features planned?
Erik Hatcher wrote:
On Feb 15, 2006, at 9:11 AM, DM Smith wrote:
Not to get to far ahead, but what is the schedule relation between
1.9 and 2.0?
What are the dependencies on releasing 2.0?
My understanding is that 2.0 will be 1.9 with all the deprecated API
removed. Maybe there are other
for me, so, barring major objections, I will
make a 1.9 RC1 release next Monday, February 20th. If there are no
problems discovered, I'll aim to make a 1.9 final release a week later,
around the 27th.
Doug
-
To unsubscribe, e-mail
: This is a great time to improve the javadoc. I see lots of blank boxes
: which could use a bit of descriptive text, for example:
That reminds me about a documentation/release issue that's been rolling
arround in the back of my mind that seems like it's only going to get
worse as future
34 matches
Mail list logo
