Right, the spreading of this constant is a bit worrisome but it seems to be the way Lucene is going. I think getTargetLuceneVersion() is a good addition to SearchTestCase.
In the hopefully near future, this constant will be a parameter of Hibernate Search at runtime. The DSL will absorb this complexity to the user. So I don't think migrating the test suite further makes sense. +1 for the commit with the addition of getTargetLuceneVersion() On 7 févr. 2010, at 22:53, Sanne Grinovero wrote: > 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 <hibern...@ferentschik.de>: >> Fine with me :) >> >> On Sun, 07 Feb 2010 15:50:13 -0300, Sanne Grinovero >> <sanne.grinov...@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. >> >> >> > _______________________________________________ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
