Just one thought...
For me it would be natural to be never confronted with the Version.xx thing in
the api unless you really need.
so f.e. having
new QueryParser("", new KeywordAnalyzer()).parse("content: the");
as a default (probably using Version.LUCENE_CURRENT under the hood), but having
new QueryParser(Version.XXX,"", new KeywordAnalyzer()).parse("content:
the");
as well.
Of cause this would require a lot of method/constructor overloading, but would
make the api more user friendly for those who write some code where the version
don't matter...
Johannes
On Feb 26, 2010, at 11:27 AM, Paul Taylor wrote:
> Robert Muir wrote:
>> such projects can do this, in one place:
>>
>> public static final Version MY_APP_CURRENT = Version.LUCENE_30;
>>
>> then later....
>>
>> StandardAnalyzer analyzer = new StandardAnalyzer(MY_APP_CURRENT);
>>
>> then they have complete control of this, independent of when the upgrade
>> lucene's jar file!
> Not quite true because you still need to update MY_APP_CURRENT when there is
> a new version, but yes thats more mangeable
>
> Paul
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
> For additional commands, e-mail: java-user-h...@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-user-h...@lucene.apache.org
