Hi Mike, here is why it fails exactly: If you drop contrib-queries.jar along with lucene-core-2.4.jar into your application and you try to use the new TrieUtils, it fails because of two things:
a) The new constructor of SortField(....., FieldCache.Parser parser) is not available in 2.4 -> MethodNotFoundException (this would happen normally) b) FieldCache.Parser is not existent in 2.4, so the JRE linker tries to load FieldCache.Parser from the lucene-2.4-core.jar, which fails. Because of that linking of TrieUtils class does not work -> ClassNotFoundException Because of this my advice to the java-user post was to upgrade *both* (core and queries) to 2.9-dev. It is simple not possible to use contrib-queries-2.9 with older lucene versions. Uwe ----- Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de > -----Original Message----- > From: Uwe Schindler [mailto:u...@thetaphi.de] > Sent: Monday, January 26, 2009 1:29 PM > To: java-dev@lucene.apache.org > Subject: RE: Where to download package org.apache.lucene.search.trie > > 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 --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
