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

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Sanne Grinovero-2
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
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

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

Emmanuel Bernard
I am not sure I understand everything you said. how about you take 20 mins tomorrow during our Hibernate NoORM team meeting on IRC?
Be careful, 20 mins run fast in practice :)

On 12 May 2014, at 17:38, Sanne Grinovero <[hidden email]> wrote:

> 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
> _______________________________________________
> hibernate-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev