Re: [infinispan-dev] multiple conflicting versions as dependencies (Lucene but not only)
On 3 Aug 2010, at 10:22, Sanne Grinovero wrote:
Hello,
I'm wondering how to solve ISPN-275 (Update Lucene Directory to work
with newer Lucene versions v.3.0.x)
The Lucene Directory works fine with latest Lucene 3.0.2, my doubt is
if I should bump the dependency version to that the tests are really
running against 3.0.2; they are currently run against 2.9.3.
The property <version.lucene> was local to the LD module only, to not
interfere with a potential different version in other modules: the
Query module
is depending on Search 3.2 which needs Lucene 2.9.x (and is not 100%
compatible with 3.0.x).
I would expect that we are stuck on 2.9.x.
So until Hibernate Search is able to deal properly with the newer
Lucene we should use 2.9.x as main reference, but for all potential
users using the newer Lucene I think we should have the Lucene
Directory module tested on 3.0.x too - not an easy feat with Maven
AFAIK.
Hmm. You are correct, this is tricky. It may require a separate integration module to
test stuff against 3.0.x, a module that excludes 2.9.x deps and adds 3.0.x deps. This
module must *never* be packaged into the final assembly though, as it will cause Maven to
trip up. Anyway it would just contain and run tests.
Being compatible with Hibernate Search is not the only reason, as
the
directory works fine with all Lucene versions from 2.4 to 3.x it's
useful to a broader range of users: Lucene's API changes are relevant
and intrusive, it's not easy to jump from 2.4 to 3 for existing
applications, for this reasons it's imho a great value if we keep it
tested against both branches of Lucene, at least for some time.
+1.
As said, no code changes are needed; the easy way is to add a Hudson
target using
"mvn clean test -Dversion.lucene=3.0.2", I could add a profile for
that, but still you have to invoke the build twice.
I wonder if someone has better ideas?
I wonder if the correct approach is a separate profile or a separate module. Actually
come to think of it a profile may do the trick very nicely.
As a side note, I noticed an additional inconsitency: the parent
pom.xml defines a dependency to javax.persistence:1.0 used by
infinispan-jopr-plugin but Search is going to introduce in classpath
hibernate-jpa-2.0-api; also this module is tested with hibernate-core
3.3.1; wouldn't this need to be tested by the same versions introduced
by the Query module?
I think we'd just bump the JPA version to 2.0 when the time comes. JPA will be
backward-compatible.
Cheers
Manik
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org