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.

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&gt;: > Fine with me :) > > On Sun, 07 Feb 2010 15:50:13 -0300, Sanne Grinovero > <sanne.grinovero(a)gmail.com&gt; 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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

ok will fix and apply About the Version, I've started a thread on Lucene-dev and got many interesting answers and insight: http://mail-archives.apache.org/mod_mbox/lucene-java-dev/201002.mbox/%3c5... Cheers, Sanne 2010/2/8 Emmanuel Bernard <emmanuel(a)hibernate.org&gt;: > 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 <hibernate(a)ferentschik.de&gt;: >>> Fine with me :) >>> >>> On Sun, 07 Feb 2010 15:50:13 -0300, Sanne Grinovero >>> <sanne.grinovero(a)gmail.com&gt; 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(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > >