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 <sa...@hibernate.org> 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, <st...@hibernate.org> 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 <mande...@redhat.com> > 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 <mande...@redhat.com> > > 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 <gun...@hibernate.org> > >>> 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@lists.jboss.org > >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev > >>> > >>> _______________________________________________ > >>> hibernate-dev mailing list > >>> hibernate-dev@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@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
