Java modules is going to compound this problem we already have. If projects can't get on board with correctly structuring their GroupID/Artifacts then why would they use good naming conventions for the Modules? Without good naming conventions, the risk of collisions increases. Manfred's referenced problem, of having multiple versions of the same dependency in the same classpath, is only going to become impossible with Java Modules.
Maven is at an optimal position within the community to prevent module naming from going haywire and becoming useless. I believe these two issues are intrinsically linked. On Thu, Feb 13, 2020 at 10:38 PM Manfred Moser <manf...@simpligility.com> wrote: > 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 > >
