Agreed ... which is why no one ever went down that road in the last decade...
Sander Verhagen wrote on 2020-02-13 19:35 (GMT -08:00): > Hi, y'all. (Disclaimer: I may not completely understand you're proposing.) I > wonder what problem you are really trying to solve. People by now have lost > the > absolute expectation that the groupId is authoritative or certified in any > way. > And the way that projects get moved between owners, without breaking > dependency > resolution, would become a nightmare when it'd require a change to groupIds. > Also, please don't force projects to change their groupId/artifactId combos. > We > are still struggling with dependency issues because of having multiple > versions > of the (essentially) same dependency on our classpath, because a > groupId/artifactId got changed (sometimes a decade ago). If you can drive > better behavior going forward, all the better, but other than that, and while > I > also like it when the world is nicely organized (groupId/artifactId), there > seems little to win here (and a lot to loose). > > Best regards, Sander. > > > > Sander Verhagen > [ san...@sanderverhagen.net<mailto:san...@sanderverhagen.net> ] > > On 13/02/2020 19.28, Jonathan Valliere wrote: > > Is there any kind of planned timeline to force compliance against old > projects? > > For example: > > - Force compliance > - Provide symlinks for backwards compatibility for a limited period of > time (1 year) > - Update Maven clients to provide warnings for symlinks during > builds/tests/etc > > > On Thu, Feb 13, 2020 at 10:23 PM Manfred Moser > <manf...@simpligility.com><mailto:manf...@simpligility.com> > wrote: > > > > This is a left over from bad choices made decades ago. Now Maven Central > has well documented criteria ... very contrary to nearly all other binary > repos.. > > > https://central.sonatype.org/pages/ossrh-guide.html > > https://central.sonatype.org/pages/requirements.html#correct-coordinates > > And the videos linked on the site in which I explain more as well. > > Manfred > > > Jonathan Valliere wrote on 2020-02-13 17:06 (GMT -08:00): > > > > I have been growing concerned about the process of allowing the creation > > > of > > > GroupIDs, within the Maven Central repository, which do not adhere to the > naming guidelines. i.e. the GroupID must belong to a unique domain name > controlled by the project owner. > > Even within the Apache family, there is no consistent naming enforcement. > The project I belong to, org.apache.mina adheres to the conventions but > many others do not. Apache Commons for example uses a different GroupID > for almost every sub-project within its scope. Many of them simply > starting with the word "commons" instead of "org.apache.commons". Does > > > the > > > PMC have any ideas on how to combat this? > > Cheers, > Jon > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: > dev-unsubscr...@maven.apache.org<mailto:dev-unsubscr...@maven.apache.org> > For additional commands, e-mail: > dev-h...@maven.apache.org<mailto:dev-h...@maven.apache.org> > > > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
