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>
