[infinispan-dev] [Search] Handling of mutual dependency with Infinispan

[Sanne Grinovero]

Now that finally Infinispan moved to build (and require) Java7, I'm
preparing to upgrade the Lucene Directory to Apache Lucene 4.8.

Sometimes it's trivial, some others we're out of luck and this is one
of such situations: the new Lucene code expects some new methods to
create and validate a CRC32 checksum signature of the Directory
segments.
Not too annoying - I can handle the coding - but it highlights an old
problem which is coming back.

Currently Infinispan is still using Hibernate Search 4.5, and provides
a Lucene Directory for both Lucene versions 3 and 4.
The current build provides the LuceneV4 support as an extension of the
V3 source module; this is a hack we introduced a year ago to make sure
we'd eventually be able to upgrade to Lucene4 and I was hoping now to
finally remove this fishy workaround as I initially expected it to be
a temporary measure.

But in practice such an upgrade of today would have been impossible:
Infinispan also depends on Hibernate Search. Having two different
modules in Infinispan is what enables us today to start an update to a
new version of Lucene.

I'm wondering if we should move the Lucene Directory code into
Hibernate Search; this also has licensing implications as that's using
ASL2 currently. And that's probably only moving the problem one step
down, as Infinispan Query still depends on Hibernate Search (engine)
and the Lucene Directory would still depend on Infinispan Core.

I'm not having a solution in mind; obviously we wouldn't have such a
problem if each of our projects *always* guaranteed a clean migration
path via default methods and deprecated methods, but this is a rule
which is occasionally broken: when it happens, the only thing I can
think of is that one of the two projects needs to release a tag which
has some broken components. For example, Infinispan to release
occasionally without the Query engine.

Sanne