FYI > Begin forwarded message: > > Date: 14 Jan 2015 17:30:59 CET > From: Scott Marlow <smarlow(a)redhat.com&gt; > To: Emmanuel Bernard <emmanuel(a)hibernate.org&gt; > Subject: Re: Hibernate ORM modules published as major.minor and an alias for main > > Hi Emmanuel, > > On 01/14/2015 11:06 AM, Emmanuel Bernard wrote: >> Hi Scott, >> >> In the f2f we discussed the idea of having ORM being published as major.minor and have an alias form main to the default WildFly targeted version. >> Is that in and for which WildFly version? > > I created https://issues.jboss.org/browse/WFLY-4021 and https://github.com/wildfly/wildfly/pull/6883 which got merged into WildFly 9.0. > > The change is that modules/system/layers/base/org/hibernate/4.3/module.xml was added and contains: > " > <module-alias xmlns="urn:jboss:module:1.3" name="org.hibernate.main" slot="4.3" target-name="org.hibernate"/> > " > > I think this is wrong though, as it should be: > > " > <module-alias xmlns="urn:jboss:module:1.3" name="org.hibernate" slot="4.3" target-name="org.hibernate"/> > " > > I'll reopen and push a new pull request. > > >> >> I am just trying the catch up. >> _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

The change I mentioned for WFLY-4021, is merged in for WildFly 9.0. On 01/15/2015 07:42 AM, Sanne Grinovero wrote: > Hi Scott, > I'm not sure I completely understood your email, but from the example > it looks like you're having the alias relation in the opposite > direction. The WFLY-4021 change allows an application to depend on a specific major.minor version of Hibernate ORM: <property name="jboss.as.jpa.providerModule" value="org.hibernate:4.3" /> > > We would need to have the actual jars into a module which has the > precise identifier, to match exactly the jars it contains. > Then we'd add an alias to specify that the "main" slot is the specific version. When we talked at the f2f, I said that we would do major.minor, I think that is the summary notes from the discussion. If we were to reverse the definitions, so that org.hibernate:main is an alias for a specific version of ORM (whether its using major.minor or major.minor.micro, it makes no difference to me) and that offers the advantages that your thinking of. Something to keep in mind, in this multiple ORM version world, is that the static javax.persistence api is not aware of modules currently. By the fact that WildFly always loads org.hibernate:main first, org.hibernate:main is always first in the list returned by PersistenceProviderResolver.getPersistenceProviders(). In the module aware (container) deployment code in WildFly, we do check if the persistence unit specifies a jboss.as.jpa.providerModule property and use that to load the persistence provider from the specified module. > > For example: > > ## Actual Module > <module xmlns="urn:jboss:module:1.3" name="org.hibernate" slot="4.3.8.Final"> > <resources> > <resource-root path="xyz-4.3.8.Final" /> > <.... > </resources> > ... > </module> > > ## The alias > <module-alias xmlns="urn:jboss:module:1.3" > name="org.hibernate" slot="main" > target-name="org.hibernate" target-slot="4.3.8.Final" /> > > By using this structure you can allow most applications to simply > depend on "org.hibernate" at slot "main". This is useful for the > majority of users, who know they want to depend on Hibernate and are > not too fuzzy about the version they use, or simply want the > "recommended" version, which is essentially what you decide is by > pulling upgrades into WildFly. > > But some of our frameworks who might need to depend on a specific > version of ORM would have the option to explicitly depend on > "org.hibernate" slot "4.3.8.Final", which is what we occasionally > need. > Also this would make it possible for the ORM project to release > "update packs", say a version 4.3.9.Final is released soon: users > would be able to drop this into their application server using slot > "4.3.9.Final" without risking to break other applications. > > We could also be a bit more fine-grained: are you still keeping > Hibernate 3 around in WildFly 9? My plan was to remove the Hibernate 3 integration code. I started doing that about a year ago or so, on a WildFly branch that (almost) works against Hibernate master from back then. That branch is very dusty now. Is there going to be a stable ORM 5.0 branch soon? At some point, we can resume integrating Jipijapa with ORM 5.0 and integrating that with WildFly (not sure if that will be WildFly 9 or 10). > If yes, you might want to have a structure like this one: > > ## Actual Module > <module xmlns="urn:jboss:module:1.3" name="org.hibernate" slot="4.3.8.Final"> > <resources> > <resource-root path="xyz-4.3.8.Final" /> > </resources> > ... > </module> > > ## The 4.x alias > <module-alias xmlns="urn:jboss:module:1.3" > name="org.hibernate" slot="4.x" > target-name="org.hibernate" target-slot="4.3.8.Final" /> > > ## The main alias > <module-alias xmlns="urn:jboss:module:1.3" > name="org.hibernate" slot="main" > target-name="org.hibernate" target-slot="4.x" /> > > One could also think of introducing a 4.3.x level.. possibilities are > endless but the priority for us would be to be able to call out a > specific version. > > Thanks, > Sanne > > > > On 14 January 2015 at 17:12, Emmanuel Bernard <emmanuel(a)hibernate.org&gt; wrote: >> FYI >> >>> Begin forwarded message: >>> >>> Date: 14 Jan 2015 17:30:59 CET >>> From: Scott Marlow <smarlow(a)redhat.com&gt; >>> To: Emmanuel Bernard <emmanuel(a)hibernate.org&gt; >>> Subject: Re: Hibernate ORM modules published as major.minor and an alias for main >>> >>> Hi Emmanuel, >>> >>> On 01/14/2015 11:06 AM, Emmanuel Bernard wrote: >>>> Hi Scott, >>>> >>>> In the f2f we discussed the idea of having ORM being published as major.minor and have an alias form main to the default WildFly targeted version. >>>> Is that in and for which WildFly version? >>> >>> I created https://issues.jboss.org/browse/WFLY-4021 and https://github.com/wildfly/wildfly/pull/6883 which got merged into WildFly 9.0. >>> >>> The change is that modules/system/layers/base/org/hibernate/4.3/module.xml was added and contains: >>> " >>> <module-alias xmlns="urn:jboss:module:1.3" name="org.hibernate.main" slot="4.3" target-name="org.hibernate"/> >>> " >>> >>> I think this is wrong though, as it should be: >>> >>> " >>> <module-alias xmlns="urn:jboss:module:1.3" name="org.hibernate" slot="4.3" target-name="org.hibernate"/> >>> " >>> >>> I'll reopen and push a new pull request. >>> >>> >>>> >>>> I am just trying the catch up. >>>> >> >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

> On 15 Jan 2015, at 14:56, Scott Marlow <smarlow(a)redhat.com > <mailto:smarlow@redhat.com>> wrote: > > When we talked at the f2f, I said that we would do major.minor, I think > that is the summary notes from the discussion. > > If we were to reverse the definitions, so that org.hibernate:main is an > alias for a specific version of ORM (whether its using major.minor or > major.minor.micro, it makes no difference to me) and that offers the > advantages that your thinking of. I think what Sanne propose is what he and I had in mind when we discussed at the f2f. I think it makes a bit more sense.

On 15 Jan 2015, at 16:54, Scott Marlow <smarlow(a)redhat.com&gt; wrote: The part that I am unsure about is including the micro version in the module path, which means that every release of WildFly that includes an upgraded Hibernate, will likely have the jars in a different path (could be a pain for any configuration settings that point to the Hibernate jars). The actual module path would also move around a lot in git, which is annoying but I have no real complaints about that. On that I am neutral. I remember Sanne advocated this but I forgot the rational nor if I was convinced ;)