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>







Reply via email to