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

[Max Rydahl Andersen]

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