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
