>From the very start of the work on the module system and throughout the work >people from the Maven project have been involved.
There was never a willingness to create any sort of enforcement.. only a request to the community to do the right thing >From my point of view the Maven project can not do anything really. With binary repositories all over the place that have very little to no enforcement what happens in Maven Central can at best be a good example. At worst a system that everyone avoids.. Things like github binaries, dockerhub, npmjs, bintray and many others have very little to no guidance or enforcement ... The burden lies with the user not to be cheated. Manfred PS: and the cynic in me says that there are plenty of "open source security" companies out there that want to "help" you and provide tooling to organize the mess, so they of course have very little to no interest to have clear ownership and rules in repositories... Maven Central is really the only place with some real rules. Jonathan Valliere wrote on 2020-02-13 20:28 (GMT -08:00): > 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 >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
