<div dir="ltr">Hi,<div><br></div><div>Users of the different Hibernate projects often wish to upgrade their WildFly installation to the latest releases of Hibernate ORM, Search or Validator.</div><div><br></div><div>For that purpose we began to provide ZIP files containing the newer JARs and module.xml descriptors, to be unzipped into the server&#39;s module directory. We use separate slot names, so to not overwrite existing modules but just add newer versions next to them.</div><div><br></div><div>But sometimes redefining the default slot actually is desirable. If an update for instance is just a bugfix release, it&#39;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.</div><div><br></div><div>But as I said we don&#39;t want to mess with any existing modules, so I&#39;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 &quot;base&quot; layer, without physically altering them. The user can go back to the original ones just by removing an entry in layers.conf.</div><div><br></div><div>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?</div><div><br></div><div>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&#39;d also be volunteering to provide it, it shouldn&#39;t take too long.</div><div><br></div><div>Thanks for any hints,</div><div><br></div><div>--Gunnar</div></div>