Ahh OK good. I misunderstood, thinking that existing apps (based on
Lucene 2.4) would break if they dropped in the trunk JAR.
Requiring the trunk lucene JAR to play with the trunk trie is
completely fine.
I'll open an issue to strengthen our back-compat tests to do "JAR drop-
in" test... my "ant" skills are not great so if someone else feels the
itch that'd be wonderful :) Else maybe I'll try to figure it out...
Mike
Uwe Schindler wrote:
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
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
