The last version of org.hibernate:hibernate-orm-modules that is available in Maven Central is 5.3.0.CR1 (for Wildfly 11). Does the fact that there are no newer versions mean that this distribution has been discontinued? Should something else be used instead now?
That looks like an issue to me.
The module was renamed to hibernate-orm-jbossmodules as of 5.3.0.CR2.
Remember also: it’s no longer a plain zip file. It’s a WildFly “feature pack” now, quite more flexible.
See https://docs.jboss.org/hibernate/orm/5.3/topical/html_single/wildfly/Wildfly.html
So in a way the old hibernate-orm-modules have been discontinued; hopefully you’ll like the new pack better.
Ok, got it. Now I’m trying to figure out how to add a feature pack (namely the one representing Hibernate version 5.3.1.Final) to an existing Wildfly installation. Using the “old” package org.hibernate:hibernate-orm-modules this was simply copying it over. While I can find ways how to include the feature pack to create a Wildfly distribution using the Maven or Gradle provisioning plugins (Using latest Hibernate ORM within WildFly), I can’t find any documentation explaining how to add/upgrade an existing Wildfly installation. The reason I believe this should be possible is https://developer.jboss.org/wiki/WildflyProvisioning, which clearly mentions this as one use case:
Install an additional feature pack on an existing server
If it turns out that this is currently not possible, would it be possible to re-introduce the “old” packages and continue publishing them until this becomes possible? We were looking forward to start using JPA 2.2/Hibernate 3 for our existing infrastructure, but coming back to your hope that we’ll like the feature packs more, well, not yet.
That’s interesting feedback, thanks!
To be fair we had not heard much from users using our module zips and so far our primary “customer” has been our own needs for integration tests across multiple projects, which is addressed better by the new feature packs - and didn’t consider existing WildFly installations.
WildFly 13 is upgrading to Hibernate ORM 5.3.1 and frankly has much better integration than what we could do by dumping a zip with some files in it: WildFly 13 takes care of automatically binding to the other services correctly, such as the clustered subsystem for distributed caching, the right JTA subsystem, CDI, etc…
With the modules as they are you don’t have any caching at all - let alone in a cluster.
We will never be able to match that level of integration with the old approach, so ideally the feature pack system should “evolve” enough to support existing systems. (Maybe that’s possible already?) I will forward this to get attention from the right people … however WildFly is also moving on to a more powerful feature pack system called Galleon - sorry it’s all a bit in flux at this point.
So I don’t think we’ll restore the zip files for the time being as I’m looking forward to better solutions and we can’t afford to maintain many different approaches. (Though if you want to send a patch I would likely accept it).
If those new R&D directions should fail we could reconsider… in the meantime I would suggest you could “provision” the new pack into an empty directory, then copy over the modules you need?
Or update to WildFly 13 and benefit from the better integration, it’s going to be released in just some days 
Thanks for sharing these insights. Its good to know that Wildfly 13 is ante portas and will contain Hibernate 5.3.x.
Good idea. I will try.
For the record, I tried. Unfortunately, that’s not helpful either. Provisioning Hibernate’s feature pack only into an empty directory does not result in something equal, even not similar, to what was packaged by hibernate-orm-modules. It seems pretty much like a “normal” Wildfly distribution (containing bin, docs, domain, standalone, welcome-content folders) and the modules folder contains a whole lot of modules that don’t seem to be all transitive dependencies of Hibernate.
(sorry for the delay, didn’t notice your follow up)
The Hibernate ORM feature pack depends on the WildFly “full” feature pack, so when you provision it it will also provision WildFly full by default - but you can override such defaults.
You will likely want it to actually copy the jar files into the modules as well:
<server-provisioning xmlns="urn:wildfly:server-provisioning:1.2" server-provisioning exclude-dependencies="true" copy-module-artifacts="true" > <feature-packs> ...
More details can be found at https://github.com/wildfly/wildfly-build-tools and specifically in https://github.com/wildfly/wildfly-build-tools/blob/master/provisioning/src/main/resources/wildfly-server-provisioning-1_2.xsd