[infinispan-dev] multiple conflicting versions as dependencies (Lucene but not only)

[Manik Surtani]

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 at jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org