4:34 p.m.
Hi all,
Tomaž is helping me figure out how we could publish a WildFly feature
pack when we do an Hibernate Search release.
We already did publish "modules" in a zip format, uploaded to the
Maven repository so that people could easily layer a bleeding edge
version on top of a slightly outdated WildFly version.
We have been doing this for a couple of years now.
It's important for our users to have a little bit of flexibility on
the exact versions.
While it's great for the huge population of Hibernate users to find
both Hibernate ORM and Hibernate Search "out of the box" in WildFly,
for the minority of those power users which actually help us by
contributing or testing each and every release they need to be able to
continue "layering" the latest of our releases without waiting for a
WildFly release.
Not least, that's essential for us to be able to catch bugs ourselves
and run every snapshot on integration tests on WildFly.
Ales, Tomaž and myself were looking for a way to DRY on the module
definitions: as we do far more integration tests of these modules in
"upstream" Hibernate Search than what is feasible for us to maintain
within the WildFly codebase, it recently happened that the modules in
WildFly were lagging behind (structurally different) and not good
enough for CapeDwarf purposes. Not an issue for the mass of Hibernate
users, but still something we'd want to prevent from happening again.
So one solution could be move all our integration tests into WildFly,
but that will slow down your build, and still force us all to maintain
two sets of identical modules.
The other idea is for WildFly to download our feature pack during the
assembly of the distribution, and rely on our integration tests. Tomaž
actually has a nice branch showcasing how this could work already.
But it looks like that if it's up to us to pre-package these modules
in advance, we should be using the "main" slot for the modules, as
they are copied "as is" into the distribution - while we always
considered the usage of the "main" slot as a prerogative of components
tightly coupled with the WildFly version.
This would imply that when someone fetches our "latest" version and
overlays it on WildFly, he would literally overwrite the bits which
were shipped with Wildfly, I don't like that idea.
Proposal:
we'll publish feature packs which make use of the slot to qualify each
distribution of our "upstream modules" with a version in format
"major.minor"; the WildFly build should then download these and
include them as-is, but also include an alias with slot "main"
pointing to the exact version which is being included in the WildFly
release.
We're already using a similar approach between Infinispan and
Hibernate Search versions - to use both qualified versions and aliases
- as they both publish modules (in different cycles) and yet depend on
each other. This approach made it feasible.
WDYT?
BTW we're paving the road with Hibernate Search, but consider it just
an example as several other projects are interested to follow up with
a similar scheme.
Thanks,
Sanne