lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hoss Man (JIRA)" <>
Subject [jira] Updated: (LUCENE-1887) o.a.l.messages should be moved/renamed
Date Tue, 08 Sep 2009 18:11:57 GMT


Hoss Man updated LUCENE-1887:

    Fix Version/s:     (was: 2.9)

bq. These classes have not relation with the queryparser code, the queryparser only uses it.

that seems like a pretty strong argument to promote it into it's own contrib ... no other
contrib is going to start depending on queryParser just to get access to a messages class
-- And if we wait until 3.x to move it to it's own contrib, we make a lot of headaches for
any users who start(ed) using the queryParser contrib in 2.9, because all of hte sudden their
code will stop working at runtime because the classes can't be found.

(it's an easy problem to fix: tell them to use the new jar as well, but it reflects badly
on the project when people encounter annoyances like that when upgrading)

That said: i'm not going to argue that hard if no more closely involved in the contrib thinks
it's worth moving .. removing 2.9 fix-for.

> o.a.l.messages should be moved/renamed
> --------------------------------------
>                 Key: LUCENE-1887
>                 URL:
>             Project: Lucene - Java
>          Issue Type: Improvement
>            Reporter: Hoss Man
>            Priority: Minor
> contrib/queryParser contains an org.apache.lucene.messages package containing some generallized
code that (claims in it's javadocs) is not specific to the queryParser.
> If this is truely general purpose code, it should probably be moved out of hte queryParser
contrib -- either into it's own contrib, or into the core (it's very small)
> Alternately: if the code isn't super reusable, the package name should probably be changed
to be a subpackage of  org.apache.lucene.queryParser ... it tends to be very confusing when
all of the code in a contrib doesn't fall into a clear organizational namespace.
> I've marked this issue for 2.9 so we at least think about it prior to release ... it
is a brand new public API, so this is out best chance to change it if we want ... but it is
by no means a blocker for 2.9

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message