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

Sanne Grinovero sanne at hibernate.org
Wed Oct 5 05:13:43 EDT 2016


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


More information about the hibernate-dev mailing list