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