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

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(a)infinispan.org&gt; wrote: