Hi,
Users of the different Hibernate projects often wish to upgrade their
WildFly installation to the latest releases of Hibernate ORM, Search or
Validator.
For that purpose we began to provide ZIP files containing the newer JARs
and module.xml descriptors, to be unzipped into the server's module
directory. We use separate slot names, so to not overwrite existing modules
but just add newer versions next to them.
But sometimes redefining the default slot actually is desirable. If an
update for instance is just a bugfix release, it's sensible to push this to
the main slot so users can benefit from it without having to explicitly
specify a slot name, suppress any implicit default module and so on.
But as I said we don't want to mess with any existing modules, so I've been
looking into alternatives. One thing I found was to provide the updated
modules in a separate layer, which then overrides the original modules from
the "base" layer, without physically altering them. The user can go back to
the original ones just by removing an entry in layers.conf.
That works nicely, but then I also learned about the patch mechanism. So I
wondered whether that should be the approach for us to follow, e.g. I also
saw that Weld is providing patches for WF. Is this then the officially
recommended way (TM) for upstream projects for shipping easy-to-use updates
of their components for WF?
One thing getting in the way of this is the lack of a Maven plug-in for the
patch-gen tool. This makes patch creation quite unwieldy in an automated
build process. Is there any chance for getting a Maven plug-in for
patch-gen? If there is interest, I'd also be volunteering to provide it, it
shouldn't take too long.
Thanks for any hints,
--Gunnar