How would changing the GroupID cause diamond dependencies? The builds would just fail everywhere until the GroupID is updated in the pom files. One thing I suggested was to create a new ID with all the old versions going back in time and simply redirect the old ID to the new one and mark it as deprecated/locked somehow so anytime you run Maven you get a big warning about the deprecated GroupID and the suggestion how to fix the pom. After a few years simply kill off the old GroupID.
The other issue is Artifacts and Automodule names. Automodules are going to be around for a long time because no one wants to build two jars for pre and post J9. On Fri, Feb 14, 2020 at 8:11 AM Elliotte Rusty Harold <elh...@ibiblio.org> wrote: > Changing group IDs of existing projects is a very bad idea. 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-stealing-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. > > 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 > > > > > > > > > > -- > Elliotte Rusty Harold > elh...@ibiblio.org > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > -- CONFIDENTIALITY NOTICE: The contents of this email message and any attachments are intended solely for the addressee(s) and may contain confidential and/or privileged information and may be legally protected from disclosure.
