Le vendredi 14 février 2020, 14:11:07 CET Elliotte Rusty Harold a écrit : > Changing group IDs of existing projects is a very bad idea. there is relocation strategy: https://maven.apache.org/guides/mini/guide-relocation.html but AFAIK, it is under-tested...
> Not only > does this break too many projects to count that are in production > today. It also introduces diamond dependencies and weird classpath > issues into projects because the same classes can now be pulled in > from multiple artifact jars. In Java 9+ compiles the breakage would > early. immediate, and complete though still hard to debug and work > around. In Java 8-, the breakage could be subtle and unnoticed. See > https://jlbp.dev/JLBP-6.html for more details. > > There are efforts underway to improve the provenance and vouching of > open source artifacts to avoid issues like the ones that affected NPM: > https://www.csoonline.com/article/3324599/hacker-adds-malicious-bitcoin-stea > ling-code-to-popular-javascript-library.html > > However in many ways Maven is already ahead of the curve here, and > much better than it was 15 years ago. I'm not sure enforcing group IDs > as domain names, even if we could do that, would materially improve > our security posture. +1 > > On Thu, Feb 13, 2020 at 10:28 PM Jonathan Valliere > > <jon.valli...@emoten.com> 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> > > > > 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 > > > 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
