Actually the patch is needing an update;
I'm extensively using a syntax like :
QueryParser parser = new QueryParser( Version.LUCENE_CURRENT, "id",
SearchTestCase.standardAnalyzer );
This "Version" constant is spread around everywhere, you have to
specify it at every QueryParser and Analyzer construction, and in many
other features. I didn't use a single constant because I was trying to
follow Emmanuel's direction of having the tests look as good examples.
On the Lucene community (see mailing list) they're strongly advising
me against using the LUCENE_CURRENT value, but to use a parameter for
the testsuite;
so I'll have to add some helper method in SearchTestCase (or other
utility) like "getTargetLuceneVersion()".
For now I'll only introduce the getter method returning
LUCENE_CURRENT, so we can later introduce logic in this getter and
eventually run tests on different versions (like a parameter of the
maven profile).
What about moving the QueryParser building to this utility class?
Seems a logic move to encapsulate a bit more, but it will loose even
more expression as a readable example.
Sanne
2010/2/7 Hardy Ferentschik <hibernate(a)ferentschik.de>:
Fine with me :)
On Sun, 07 Feb 2010 15:50:13 -0300, Sanne Grinovero
<sanne.grinovero(a)gmail.com> wrote:
> Hello,
> I've prepared a patch for HSEARCH-458, there's nothing critically
> complex inside but it's more than 3000 lines of tedious work.
> It patches almost nothing in main, nearly all classes in test.
> It changes the way we use Lucene's API, for each deprecated method
> I've rewritten it to use the new API,
> so the immediate effect will be to only reduce some warnings, but this
> is going to be a requirement when switching to Lucene 3.x
> (Lucene 2.9 deprecated the APIs, 3.x removed them)
>
> ok for commit?
> If you need to take a look inside, I've attached the patch to JIRA.
>
> This is not about upgrading to Lucene3: it's still compatible with
> 2.9, but will make upgrade easier later.