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

[Ryan Emerson]

Hi Sanne,

Thanks for the input and the proposed solution. I am not familiar 
with Hibernate search and our integrations, so I will leave others to
comment on the version upgrade. I just wanted to let you know that the
transition to feature-packs is on the roadmap for 9.3 as part of our
ongoing server refactoring efforts. Furthermore, I believe the breaking
of the wildfly-modules was caused by my work on the bom and parent pom
refactoring, so apologies for the inconvenience, I owe you a beer!

Cheers
Ryan

----- Original Message -----
> 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
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>