Won't this break like every existing example and 3rd party integrations (think Spring projects) maven and gradle builds on the planet ? Or are hibernate 6 so radically different there is no chance you would just change the version number to have builds work with both hibernate 5 and 6 ? Not saying it should not be done - just wondering if we grok the full impact for users. /max /max http://about.me/maxandersen

Right, that'd be my hope as well. It'll just more clearly emphasize which artifacts "belong together" because they are part of the same project. More fine-grained group ids also help with discoverability of the modules of one project. E.g. try to find all the backends for Hibernate Search from this list of >80 artifacts under org.hibernate: http://mvnrepository.com/artifact/org.hibernate. It looks much more digestable for OGM: http://mvnrepository.com/artifact/org.hibernate.ogm which already uses its own group id. Taking Spring as an example, they also have different group ids for things like Spring Data, Spring Integration etc. I don't think it harms their brand. But yes, it'll be a migration challenge, needing good communication and education. Personally I think that's acceptable for a major version, esp. if we happen to do it at the same major (6) for ORM, Search and Validator. --Gunnar 2016-10-05 11:13 GMT+02:00 Sanne Grinovero <sanne(a)hibernate.org&gt;: > Hi Max, > > the intent is to publish "relocation artifacts" like this one which we > created when the Hibernate Search main artifact was renamed from > "org.hibernate:hibernate-search" to > "org.hibernate:hibernate-search-orm" > > https://raw.githubusercontent.com/hibernate/hibernate- > search/master/legacy/pom.xml > > If the tool in question respects the Maven relocation rules, when > consuming the old coordinates you'd get a warning and be transparently > served the new coordinates. Maven itself works fine with this, I don't > know about other tools.. I've heard no complaints from the Search > users but of course that's a smaller population and not many tools > AFAIK, so I'm looking forward for feedback on more specific problems. > > It's not clear yet however if we'll actually do this and for how long, > as e.g. Gradle seems to not be able to produce these so we'll need to > possibly hack a custom plugin for this? > > In the chat with Steve yesterday we both agreed that we shouldn't do > this forever, but to treat it like a deprecated method; so it seems > sensible to keep it for the lifetime of ORM 6.x. > In the case of the above Search example we kept it for longer, as it's > doing no harm and is not in the way as much as maintaining deprecated > code could be. > > I actually have one concern, after a night of sleep :) > This might be just something that *we* like to see as maintainer in > terms of order, but I'm wondering if this organization makes sense for > end users. Considering the "groupId" to be pretty much an > "organization id", I'd wager that consumers see us as one consistent > entity, and we'd be possibly damaging the brand. > > We keep some of our projects in separate repositories as it would > otherwise be too much maintenance and synchronization work, but > several users have expressed that this is confusing and they'd rather > see us, among others, align version numbers and release schedules. > > Also I guess one reason for the "groupId" to exist at all is to help > ensuring uniqueness of artifact ids among the whole ecosystem, so that > people not aware of each other don't step on each others toes.. but > that's certainly questionable in our case as we can easily discuss > naming of new modules among us. > > I just wonder if we're not going in opposite direction of usability > for our own sake of selfish sense of organization. > As ultimately, that's what is often unclear.. > > Thanks, > Sanne > > > > On 5 October 2016 at 07:30, Max Rydahl Andersen <manderse(a)redhat.com&gt; > wrote: > > Won't this break like every existing example and 3rd party integrations > > (think Spring projects) maven and gradle builds on the planet > > ? Or are hibernate 6 so radically different there is no chance you would > > just change the version number to have > > builds work with both hibernate 5 and 6 ? > > > > Not saying it should not be done - just wondering if we grok the full > impact > > for users. > > > > /max > > > > > >> No concerns. > >> When talking about this with Steve I also added it to our next meeting > >> agenda, however it looks like we're all onboard so maybe there isn't > >> much to debate :) > >> > >> On 4 October 2016 at 19:19, Gunnar Morling <gunnar(a)hibernate.org&gt; > wrote: > >>> > >>> Hi, > >>> > >>> I just stumbled across HHH-11153 ("Rename published groupId from > >>> org.hibernate to org.hibernate.orm"), scheduled for ORM 6.0.0.Alpha1. > >>> > >>> I think that's a great idea and would suggest we do the same for > >>> Hibernate > >>> Validator and Search in their respective 6.0 releases: > >>> org.hibernate.validator and org.hibernate.search (for OGM we used > >>> org.hibernate.ogm from the beginning). > >>> > >>> Any concerns? > >>> > >>> --Gunnar > >>> _______________________________________________ > >>> 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 > > > > > > > > /max > > http://about.me/maxandersen >

The grouping is certainly "nice". But given the possibility of difficulties renaming the groupId could have for users I'd not make this change just because it is nice. No, this is part of a larger change I want to do which is laid out in the JIRA Gunnar mentioned. Specifically I want to move away from publishing to JBoss Nexus and instead publish directly to Sonatype's OSSRH offering. On Wed, Oct 5, 2016, 5:32 PM Max Rydahl Andersen <manderse(a)redhat.com&gt; wrote:

It's more a convenience of defining the rsync that currently happens between JBoss and Central. On Wed, Oct 5, 2016, 5:48 PM Sanne Grinovero <sanne(a)hibernate.org&gt; wrote:

Do we need to create relocation artifacts for new modules only added after the group id change? There won't be wrong references to these out in the wild, so people should be fine without them? Either way I think if ORM changes it in 6, we should do it consistently for HV/HSEARCH, too, as it will be less confusing down the road. 2016-10-06 4:10 GMT+02:00 Steve Ebersole <steve(a)hibernate.org&gt;: > To clarify my last reply... > > Today all of the artifacts under org.hibernate are published to JBoss Nexus > and then rsync'ed to Central. When I move to publishing the artifacts for > ORM to Central "directly" (via OSSRH), those artifacts need to be excluded > from the rsync. But today, because all (most) of the projects use > org.hibernate as the groupId there is no single directory I can say to > exclude. Instead we'd have to list the ORM artifacts explicitly, > individually. The problem ofc being when we add a new module to ORM we'd > have to remember to add that to the list of exclusions. > > > On Wed, Oct 5, 2016 at 8:04 PM Steve Ebersole <steve(a)hibernate.org&gt; wrote: > > > It's more a convenience of defining the rsync that currently happens > > between JBoss and Central. > > > > On Wed, Oct 5, 2016, 5:48 PM Sanne Grinovero <sanne(a)hibernate.org&gt; > wrote: > > > > Are we required to change groupId for that? > > Asking mainly to get OGM there as well, as it's already using the > proposed > > scheme. > > > > On Wed, 5 Oct 2016, 23:44 Steve Ebersole, <steve(a)hibernate.org&gt; wrote: > > > > The grouping is certainly "nice". But given the possibility of > > difficulties renaming the groupId could have for users I'd not make this > > change just because it is nice. No, this is part of a larger change I > want > > to do which is laid out in the JIRA Gunnar mentioned. Specifically I > want > > to move away from publishing to JBoss Nexus and instead publish directly > to > > Sonatype's OSSRH offering. > > > > On Wed, Oct 5, 2016, 5:32 PM Max Rydahl Andersen <manderse(a)redhat.com&gt; > > wrote: > > > > yes, with relocation artefacts things could be made less annoying. > > > > Just wanted to be sure we at least considered it and I hope you can get > > Gradle to play nice ;) > > > > /max > > > > > Hi Max, > > > > > > the intent is to publish "relocation artifacts" like this one which we > > > created when the Hibernate Search main artifact was renamed from > > > "org.hibernate:hibernate-search" to > > > "org.hibernate:hibernate-search-orm" > > > > > > > > https://raw.githubusercontent.com/hibernate/hibernate- > search/master/legacy/pom.xml > > > > > > If the tool in question respects the Maven relocation rules, when > > > consuming the old coordinates you'd get a warning and be transparently > > > served the new coordinates. Maven itself works fine with this, I don't > > > know about other tools.. I've heard no complaints from the Search > > > users but of course that's a smaller population and not many tools > > > AFAIK, so I'm looking forward for feedback on more specific problems. > > > > > > It's not clear yet however if we'll actually do this and for how long, > > > as e.g. Gradle seems to not be able to produce these so we'll need to > > > possibly hack a custom plugin for this? > > > > > > In the chat with Steve yesterday we both agreed that we shouldn't do > > > this forever, but to treat it like a deprecated method; so it seems > > > sensible to keep it for the lifetime of ORM 6.x. > > > In the case of the above Search example we kept it for longer, as it's > > > doing no harm and is not in the way as much as maintaining deprecated > > > code could be. > > > > > > I actually have one concern, after a night of sleep :) > > > This might be just something that *we* like to see as maintainer in > > > terms of order, but I'm wondering if this organization makes sense for > > > end users. Considering the "groupId" to be pretty much an > > > "organization id", I'd wager that consumers see us as one consistent > > > entity, and we'd be possibly damaging the brand. > > > > > > We keep some of our projects in separate repositories as it would > > > otherwise be too much maintenance and synchronization work, but > > > several users have expressed that this is confusing and they'd rather > > > see us, among others, align version numbers and release schedules. > > > > > > Also I guess one reason for the "groupId" to exist at all is to help > > > ensuring uniqueness of artifact ids among the whole ecosystem, so that > > > people not aware of each other don't step on each others toes.. but > > > that's certainly questionable in our case as we can easily discuss > > > naming of new modules among us. > > > > > > I just wonder if we're not going in opposite direction of usability > > > for our own sake of selfish sense of organization. > > > On the other end, maybe grouping them together will make it clearer to > > > end users which artifacts need to use the same version? > > > As ultimately, that's what is often unclear.. > > > > > > Thanks, > > > Sanne > > > > > > On 5 October 2016 at 07:30, Max Rydahl Andersen <manderse(a)redhat.com&gt; > > > wrote: > > >> Won't this break like every existing example and 3rd party > > >> integrations > > >> (think Spring projects) maven and gradle builds on the planet > > >> ? Or are hibernate 6 so radically different there is no chance you > > >> would > > >> just change the version number to have > > >> builds work with both hibernate 5 and 6 ? > > >> > > >> Not saying it should not be done - just wondering if we grok the full > > >> impact > > >> for users. > > >> > > >> /max > > >> > > >> > > >>> No concerns. > > >>> When talking about this with Steve I also added it to our next > > >>> meeting > > >>> agenda, however it looks like we're all onboard so maybe there isn't > > >>> much to debate :) > > >>> > > >>> On 4 October 2016 at 19:19, Gunnar Morling <gunnar(a)hibernate.org&gt; > > >>> wrote: > > >>>> > > >>>> Hi, > > >>>> > > >>>> I just stumbled across HHH-11153 ("Rename published groupId from > > >>>> org.hibernate to org.hibernate.orm"), scheduled for ORM > > >>>> 6.0.0.Alpha1. > > >>>> > > >>>> I think that's a great idea and would suggest we do the same for > > >>>> Hibernate > > >>>> Validator and Search in their respective 6.0 releases: > > >>>> org.hibernate.validator and org.hibernate.search (for OGM we used > > >>>> org.hibernate.ogm from the beginning). > > >>>> > > >>>> Any concerns? > > >>>> > > >>>> --Gunnar > > >>>> _______________________________________________ > > >>>> 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 > > >> > > >> > > >> > > >> /max > > >> http://about.me/maxandersen > > > > > > /max > > http://about.me/maxandersen > > > > _______________________________________________ > > 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 >