Updating components in WildFly

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Updating components in WildFly

Gunnar Morling
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

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Updating components in WildFly

Gunnar Morling
Hi,

I've sent a pull request which provides a Maven plug-in for patch-gen: https://github.com/jbossas/patch-gen/pull/8. Tested it successfully by using it to create a patch file for updating Hibernate Validator.

I hope a release - including deployment to Nexus - of this could be done some time soon?

Thanks,

--Gunnar




2016-10-31 16:47 GMT+01:00 Gunnar Morling <[hidden email]>:
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


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Loading...