Mailing List Archive

release 1.2 RC3
I just made a new release, 1.2RC3, based on the current CVS:
http://jakarta.apache.org/builds/jakarta-lucene/release/v1.2-rc3/

I did some simple tests, and things look good to me. Does anyone see a
reason not to announce this to lucene-user? Hopefully we can turn this into
a 1.2 final release soon.

Release notes follow.

Doug

1.2 RC3

1. IndexWriter: fixed a bug where adding an optimized index to an
empty index failed. This was encountered using addIndexes to copy
a RAMDirectory index to an FSDirectory.

2. RAMDirectory: fixed a bug where RAMInputStream could not read
across more than across a single buffer boundary.

3. Fix query parser so it accepts queries with unicode characters.
(briangoetz)

4. Fix query parser so that PrefixQuery is used in preference to
WildcardQuery when there's only an asterisk at the end of the
term. Previously PrefixQuery would never be used.

5. Fix tests so they compile; fix ant file so it compiles tests
properly. Added test cases for Analyzers and PriorityQueue.

6. Updated demos, added Getting Started documentation. (acoliver)

7. Added 'contributions' section to website & docs. (carlson)

8. Removed JavaCC from source distribution for copyright reasons.
Folks must now download this separately from metamata in order to
compile Lucene. (cutting)

9. Substantially improved the performance of DateFilter by adding the
ability to reuse TermDocs objects. (cutting)

10. Added IndexReader methods:
public static boolean indexExists(String directory);
public static boolean indexExists(File directory);
public static boolean indexExists(Directory directory);
public static boolean isLocked(Directory directory);
public static void unlock(Directory directory);
(cutting, otis)

11. Fixed bugs in GermanAnalyzer (gschwarz)


--
To unsubscribe, e-mail: <mailto:lucene-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:lucene-dev-help@jakarta.apache.org>
Re: release 1.2 RC3 [ In reply to ]
Looks good to me...seems like a good idea to announce it widespread.

There is one thing I suggest we do before we do a final.
Lets create separate targets for building the javacc stuff like this:

cleancc - cleans just the javacc stuff
allclean - clean + cleancc
javacc - does the javacc stuff

we'll include pre-compiled (or whatever one calls it) javacc'd stuff.

I think this will prevent a lot of "THE BUILD IS BROKEN!!!!" messages on
both lists ;-)

Thoughts anyone?

-Andy

On Sun, 2002-01-27 at 18:24, Doug Cutting wrote:
> I just made a new release, 1.2RC3, based on the current CVS:
> http://jakarta.apache.org/builds/jakarta-lucene/release/v1.2-rc3/
>
> I did some simple tests, and things look good to me. Does anyone see a
> reason not to announce this to lucene-user? Hopefully we can turn this into
> a 1.2 final release soon.
>
> Release notes follow.
>
> Doug
>
> 1.2 RC3
>
> 1. IndexWriter: fixed a bug where adding an optimized index to an
> empty index failed. This was encountered using addIndexes to copy
> a RAMDirectory index to an FSDirectory.
>
> 2. RAMDirectory: fixed a bug where RAMInputStream could not read
> across more than across a single buffer boundary.
>
> 3. Fix query parser so it accepts queries with unicode characters.
> (briangoetz)
>
> 4. Fix query parser so that PrefixQuery is used in preference to
> WildcardQuery when there's only an asterisk at the end of the
> term. Previously PrefixQuery would never be used.
>
> 5. Fix tests so they compile; fix ant file so it compiles tests
> properly. Added test cases for Analyzers and PriorityQueue.
>
> 6. Updated demos, added Getting Started documentation. (acoliver)
>
> 7. Added 'contributions' section to website & docs. (carlson)
>
> 8. Removed JavaCC from source distribution for copyright reasons.
> Folks must now download this separately from metamata in order to
> compile Lucene. (cutting)
>
> 9. Substantially improved the performance of DateFilter by adding the
> ability to reuse TermDocs objects. (cutting)
>
> 10. Added IndexReader methods:
> public static boolean indexExists(String directory);
> public static boolean indexExists(File directory);
> public static boolean indexExists(Directory directory);
> public static boolean isLocked(Directory directory);
> public static void unlock(Directory directory);
> (cutting, otis)
>
> 11. Fixed bugs in GermanAnalyzer (gschwarz)
>
>
> --
> To unsubscribe, e-mail: <mailto:lucene-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:lucene-dev-help@jakarta.apache.org>
>
--
www.superlinksoftware.com
www.sourceforge.net/projects/poi - port of Excel format to java
http://developer.java.sun.com/developer/bugParade/bugs/4487555.html
- fix java generics!


The avalanche has already started. It is too late for the pebbles to
vote.
-Ambassador Kosh


--
To unsubscribe, e-mail: <mailto:lucene-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:lucene-dev-help@jakarta.apache.org>
RE: release 1.2 RC3 [ In reply to ]
> From: Andrew C. Oliver [mailto:acoliver@apache.org]
>
> Lets create separate targets for building the javacc stuff like this:
>
> cleancc - cleans just the javacc stuff
> allclean - clean + cleancc
> javacc - does the javacc stuff
>
> we'll include pre-compiled (or whatever one calls it) javacc'd stuff.
>
> I think this will prevent a lot of "THE BUILD IS BROKEN!!!!"
> messages on both lists ;-)

It would change the messages, but I'm not sure it would eliminate them.
Most lucene users shouldn't need to compile things. And when they do, some
of the most frequently changed things are JavaCC-based, like the query
parser and the standard tokenizer.

Folks are presented a clear message if they download the source release and
try to build it without also downloading JavaCC. The JavaCC-generated
source code is packaged with the source release, for those folks who don't
want to build with ant.

This situation should improve in the next release. The folks who own JavaCC
have agreed to grant us a special license to re-distribute the jar, but they
haven't yet had time to work out the details.

Doug

--
To unsubscribe, e-mail: <mailto:lucene-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:lucene-dev-help@jakarta.apache.org>
Re: release 1.2 RC3 [ In reply to ]
On Sun, Jan 27, 2002 at 04:49:06PM -0800, Doug Cutting wrote:
> > From: Andrew C. Oliver [mailto:acoliver@apache.org]
> >
> > Lets create separate targets for building the javacc stuff like this:
> >
> > cleancc - cleans just the javacc stuff
> > allclean - clean + cleancc
> > javacc - does the javacc stuff
> >
> > we'll include pre-compiled (or whatever one calls it) javacc'd stuff.
> >
> > I think this will prevent a lot of "THE BUILD IS BROKEN!!!!"
> > messages on both lists ;-)

-1 from me. Seems like the wrong solution. Exposes too much of the
internals of the build to the user.

Besides, most people don't need the sources; the pre-built JAR is fine
for the vast majority. If the problem is the error message, make it
clearer.

However, what I've done in other projects is this: include the
generated .java files from JavaCC in the CVS repo, in some other part
of the tree (src/generated), and if JavaCC is not found, copy from
there instead of building them. That's easy enough to automate, but
its not clear if that solves the problem -- people without JavaCC might
try to change the query parser and wonder why its not building.

I think the people who post "THE BUILD IS BROKEN" are going to do so
anyway; the current message is pretty clear that it can't find JavaCC
and what you have to do to fix it.

--
To unsubscribe, e-mail: <mailto:lucene-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:lucene-dev-help@jakarta.apache.org>
RE: release 1.2 RC3 [ In reply to ]
On Sun, 2002-01-27 at 19:49, Doug Cutting wrote:
> > From: Andrew C. Oliver [mailto:acoliver@apache.org]
> >
> > Lets create separate targets for building the javacc stuff like this:
> >
> > cleancc - cleans just the javacc stuff
> > allclean - clean + cleancc
> > javacc - does the javacc stuff
> >
> > we'll include pre-compiled (or whatever one calls it) javacc'd stuff.
> >
> > I think this will prevent a lot of "THE BUILD IS BROKEN!!!!"
> > messages on both lists ;-)
>
> It would change the messages, but I'm not sure it would eliminate them.
> Most lucene users shouldn't need to compile things. And when they do, some
> of the most frequently changed things are JavaCC-based, like the query
> parser and the standard tokenizer.
>

Gotcha.

> Folks are presented a clear message if they download the source release and
> try to build it without also downloading JavaCC. The JavaCC-generated
> source code is packaged with the source release, for those folks who don't
> want to build with ant.
>
> This situation should improve in the next release. The folks who own JavaCC
> have agreed to grant us a special license to re-distribute the jar, but they
> haven't yet had time to work out the details.
>

That's excellent news!


> Doug
>
> --
> To unsubscribe, e-mail: <mailto:lucene-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:lucene-dev-help@jakarta.apache.org>
>
--
www.superlinksoftware.com
www.sourceforge.net/projects/poi - port of Excel format to java
http://developer.java.sun.com/developer/bugParade/bugs/4487555.html
- fix java generics!


The avalanche has already started. It is too late for the pebbles to
vote.
-Ambassador Kosh


--
To unsubscribe, e-mail: <mailto:lucene-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:lucene-dev-help@jakarta.apache.org>
Re: release 1.2 RC3 [ In reply to ]
I'd like to suggest a change to the "JavaCC not found" build message. Would
it be helpful to mention the build.properties file, where the javacc.home
variable is defined?
-Lex


>From: Brian Goetz <brian@quiotix.com>
>Reply-To: "Lucene Developers List" <lucene-dev@jakarta.apache.org>
>To: Lucene Developers List <lucene-dev@jakarta.apache.org>
>Subject: Re: release 1.2 RC3
>Date: Sun, 27 Jan 2002 17:20:58 -0800
>
>On Sun, Jan 27, 2002 at 04:49:06PM -0800, Doug Cutting wrote:
> > > From: Andrew C. Oliver [mailto:acoliver@apache.org]
> > >
> > > Lets create separate targets for building the javacc stuff like this:
> > >
> > > cleancc - cleans just the javacc stuff
> > > allclean - clean + cleancc
> > > javacc - does the javacc stuff
> > >
> > > we'll include pre-compiled (or whatever one calls it) javacc'd stuff.
> > >
> > > I think this will prevent a lot of "THE BUILD IS BROKEN!!!!"
> > > messages on both lists ;-)
>
>-1 from me. Seems like the wrong solution. Exposes too much of the
>internals of the build to the user.
>
>Besides, most people don't need the sources; the pre-built JAR is fine
>for the vast majority. If the problem is the error message, make it
>clearer.
>
>However, what I've done in other projects is this: include the
>generated .java files from JavaCC in the CVS repo, in some other part
>of the tree (src/generated), and if JavaCC is not found, copy from
>there instead of building them. That's easy enough to automate, but
>its not clear if that solves the problem -- people without JavaCC might
>try to change the query parser and wonder why its not building.
>
>I think the people who post "THE BUILD IS BROKEN" are going to do so
>anyway; the current message is pretty clear that it can't find JavaCC
>and what you have to do to fix it.
>
>--
>To unsubscribe, e-mail:
><mailto:lucene-dev-unsubscribe@jakarta.apache.org>
>For additional commands, e-mail:
><mailto:lucene-dev-help@jakarta.apache.org>
>




_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.


--
To unsubscribe, e-mail: <mailto:lucene-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:lucene-dev-help@jakarta.apache.org>
Re: release 1.2 RC3 [ In reply to ]
Actually, I think it's probably better that users don't mess with
build.properties and instead define their own properties in
~/.ant.properties instead as instructed by the JavaCC check message.

Another solution is to make a symbolic link (shortcut?) from
./lib/JavaCC.zip to the real JavaCC.zip, which is what I just did.

Otis

--- Lex Lawrence <lex_lawrence@hotmail.com> wrote:
> I'd like to suggest a change to the "JavaCC not found" build message.
> Would
> it be helpful to mention the build.properties file, where the
> javacc.home
> variable is defined?
> -Lex
>
>
> >From: Brian Goetz <brian@quiotix.com>
> >Reply-To: "Lucene Developers List" <lucene-dev@jakarta.apache.org>
> >To: Lucene Developers List <lucene-dev@jakarta.apache.org>
> >Subject: Re: release 1.2 RC3
> >Date: Sun, 27 Jan 2002 17:20:58 -0800
> >
> >On Sun, Jan 27, 2002 at 04:49:06PM -0800, Doug Cutting wrote:
> > > > From: Andrew C. Oliver [mailto:acoliver@apache.org]
> > > >
> > > > Lets create separate targets for building the javacc stuff like
> this:
> > > >
> > > > cleancc - cleans just the javacc stuff
> > > > allclean - clean + cleancc
> > > > javacc - does the javacc stuff
> > > >
> > > > we'll include pre-compiled (or whatever one calls it) javacc'd
> stuff.
> > > >
> > > > I think this will prevent a lot of "THE BUILD IS BROKEN!!!!"
> > > > messages on both lists ;-)
> >
> >-1 from me. Seems like the wrong solution. Exposes too much of the
> >internals of the build to the user.
> >
> >Besides, most people don't need the sources; the pre-built JAR is
> fine
> >for the vast majority. If the problem is the error message, make it
> >clearer.
> >
> >However, what I've done in other projects is this: include the
> >generated .java files from JavaCC in the CVS repo, in some other
> part
> >of the tree (src/generated), and if JavaCC is not found, copy from
> >there instead of building them. That's easy enough to automate, but
> >its not clear if that solves the problem -- people without JavaCC
> might
> >try to change the query parser and wonder why its not building.
> >
> >I think the people who post "THE BUILD IS BROKEN" are going to do so
> >anyway; the current message is pretty clear that it can't find
> JavaCC
> >and what you have to do to fix it.
> >
> >--
> >To unsubscribe, e-mail:
> ><mailto:lucene-dev-unsubscribe@jakarta.apache.org>
> >For additional commands, e-mail:
> ><mailto:lucene-dev-help@jakarta.apache.org>
> >
>
>
>
>
> _________________________________________________________________
> Get your FREE download of MSN Explorer at
> http://explorer.msn.com/intl.asp.
>
>
> --
> To unsubscribe, e-mail:
> <mailto:lucene-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
> <mailto:lucene-dev-help@jakarta.apache.org>
>


__________________________________________________
Do You Yahoo!?
Great stuff seeking new owners in Yahoo! Auctions!
http://auctions.yahoo.com

--
To unsubscribe, e-mail: <mailto:lucene-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:lucene-dev-help@jakarta.apache.org>
RE: release 1.2 RC3 [ In reply to ]
> From: Otis Gospodnetic [mailto:otis_gospodnetic@yahoo.com]
>
> Another solution is to make a symbolic link (shortcut?) from
> ./lib/JavaCC.zip to the real JavaCC.zip, which is what I just did.

That works so long as you're not building distributions. The 'dist' and
'dist-src' targets bundle in the contents of the lib directory, and we can't
re-distribute JavaCC without permission.

I agree that the current instructions in build.xml are best.

Doug

--
To unsubscribe, e-mail: <mailto:lucene-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:lucene-dev-help@jakarta.apache.org>