Hi Mike, That's no problem. O.a.l.search.trie is a new package and depends on new features in trunk lucene. You can plug in the jar and it works with older code. The problem here is, that the package trie is compiled against new lucene 2.9 features like the new SortField constructors. Because of that, the *trie* package is not backwards compatible (you cannot drop the contrib-search package along with lucene-core-2.4).
But your test is good. Just compile the tests using an old lucene-core.jar is a good idea. And also the other way round: Use the new lucene-jars as a plugin replacement for the old compiled tests. Uwe > > You can use the artifact from Hudson as Mike told, but the JAR file > > is not > > compatible with Lucene 2.4 (because a new SortField constructor for > > sorting > > against trie encoded fields and the new Superinterface > > FieldCache.Parser > > leading to ClassNotFoundEx). > > Ugh -- this is no good: it's a break to our back-compat, I think? Ie > when we > say "complete API back-compatbility", here: > > http://wiki.apache.org/lucene-java/BackwardsCompatibility > > We mean you can drop in new JAR and run your app w/ no problems, right? > > Uwe, how could we fix it (LUCENE-1478) so we get back to "drop-in new > JAR" > back compatibility? > > Also, it'd be great to fix "ant test-tag" to somehow test "jar drop-in > back compat", > vs "full recompilation against new JAR" that it does today. It'd have > to check out > the full sources on the back-compat tag, compile JAR & tests from > those old > sources, swap in new JAR, then run the tests. > > Mike > > --------------------------------------------------------------------- > To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: java-dev-h...@lucene.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
