[hibernate-dev] Changing group ids from org.hibernate to org.hibernate.{project}

[Sanne Grinovero]

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 at 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 <manderse at 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 <manderse at 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 <gunnar at 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 at lists.jboss.org
> >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>>
> >>> _______________________________________________
> >>> hibernate-dev mailing list
> >>> hibernate-dev at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>