[infinispan-dev] Hibernate Search integration modules for WildFly have been broken

[Sanne Grinovero]

Hi all,

spent friday and a good deal of the weekend exploring some options;
finally I have a proposal.
 - https://github.com/infinispan/infinispan/pull/5766

But let me give some background:

I was originally planning to upgrade Infinispan to Hibernate Search
5.9.0.Final only in Infinispan 9.3, as while the code itself didn't
change much, I was expecting quite some work in the area of the build
of WildFly modules.

However since the module structure in the current master is lacking
[ISPN-8780] I'm proposing now to do this upgrade already, so to not
have to refactor the build of modules now and then again shortly.

As a reminder, we want Infinispan to be able to provide a "Lucene
Directory Provider" for 3 versions of Hibernate Search:
 A) the version which is included in latest WildFly stable release
 B) the version which Infinispan Query is using
 C) the latest stable version

It is of course possible - even likely - that some of these versions
happen to be the same for a particular release train; that's nice
however please remember that while they might be *coincidentally* the
same, that's no good reason to remove the capability of the build
system to support these different versions when they happen to
diverge. That's why the properties which mark each of these versions
was strictly separate - and more crucially was not "redundant".

In the specific case, I was looking for the properties I needed to
change to make sure we could support latest Hibernate Search release
but they were gone, my guess is this was caused by the fact that
recently version[B] and version[C] happened to match so this confused.

At this stage I don't think it's worth it to try find and identify all
changes which should be reverted, as with the upcoming upgrade to
Hibernate Search 5.9.0.Final several changes in how we build modules
would be needed, so I'll send a PR to upgrade to HS 5.9.0.Final
already.

Risks and implications?

HS 5.9 is mostly the same as 5.8, the main difference for end users is
the integration with a different version of Hibernate ORM now
supporting JPA 2.2 - but this isn't relevant for Infinispan so I
consider the upgrade overall a low risk.
The other relevant difference is that we no longer publish a zip of
the modules for WildFly - we publish instead a set of rather fine
grained feature packs. This is good news for Infinispan as we can
better cherry pick which components you actually want, but it means
the build needs to be adapted now to deal with these feature packs.

In my PR for ISPN-8779 I'll use the Provisioning plugin for Maven to
materialize the modules that Infinispan needs, so that for now they
can be re-packaged into the zip files - so to not have any impact on
Infinispan users. I hope in a second stage you'll all see the benefits
of distributing feature packs so we'll be able to simplify some
things.

Feature packs normally have a notion of dependency to other feature
packs, but to keep the adaptation into "old style fat zip" I'll
reconfigure the provisioning task to disable transitive dependencies;
the drawback is that I'll have to declare the version of each feature
pack we need explicitly in the parent pom: we'll be able to avoid the
need to match the dependant versions when Infinispan also will produce
feature packs rather than the fat zip.

N.B. this PR #5766 doesn't address the fact that the build doesn't
differentiate between the above cases B and C, but since B and C would
just happen to be the same version again in Infinispan 9.2 the issue
is no longer urgent, so ISPN-8780 could be postponed to 9.3+ and it
might be much easier after migrating some Infinispan modules to
feature packs as well.

Thanks,
Sanne


On 7 February 2018 at 16:59, Sanne Grinovero <sanne at infinispan.org> wrote:
> Hi all,
>
> I was going to give ISPN-8779 a shot but I'm finding a mess.
>
> the root pom contains these twice (and inconsistent!):
>
> <version.hibernate.search>5.8.1.Final</version.hibernate.search>
> [...]
> <version.hibernate.search>5.8.0.Final</version.hibernate.search>
>
> the BOM cointains a copy of `version.hibernate.search` as well.
>
> I don't mind deleting duplicate properties, but we used to have
> clearly separate properties for different purposes, and this
> separation is essential.
>
> I've mentioned this multiple times when reviewing PRs which would get
> my attention, but I didn't see these changes - certainly didn't expect
> you all to forget the special purpose of these modules.
> It's quite messy now and I'm honestly lost myself at how I could revert it.
>
> In particular this module is broken now as it's targeting the wrong slot:
>  - https://github.com/infinispan/infinispan/blob/master/wildfly-modules/src/main/resources/org/infinispan/for-hibernatesearch-wildfly/main/module.xml#L27
>
> Clearly it's not consistent with the comment I've put on the module descriptor.
> I don't see that module being included in the released modules either,
> and clearly the integration tests didn't catch it because they have
> been patched to use the wrong modules too :(
>
> Other essential integration tests which I had put in place to make
> sure they'd get your attention in case someone had such an idea.. have
> been deleted.
>
> Opening ISPN-8780, I would consider this a release blocker.
>
> Thanks,
> Sanne
>
> See also:
>  - https://github.com/infinispan/infinispan/blob/master/integrationtests/as-lucene-directory/READ.ME