If Central indicated a redirect/reallocation then there would never be the duplicate classpath problem because Maven would resolve it internally. The redirect then warns the user of the redirect and to update the pom.
On Sat, Feb 15, 2020 at 1:10 PM Elliotte Rusty Harold <elh...@ibiblio.org> wrote: > On Sat, Feb 15, 2020 at 10:55 AM Jonathan Valliere > <jon.valli...@emoten.com> wrote: > > > > How would changing the GroupID cause diamond dependencies? The builds > > would just fail everywhere until the GroupID is updated in the pom files. > > No, they wouldn't. What happens is two artifacts get added to the > classpath, one with the new group ID and one with the old group ID. In > Java 8 and earlier the program will continue to compile and run until > some code that depends on the newer version happens to get a class > from the older version or vice versa. It's a mess. > > In Java 9 and later the failure happens earlier and more reliably but > it's still confusing and difficult to debug and fix. > > > 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. > > Nope. A fundamental principle of the Maven repository system is that > once an artifact is published it's there forever and will not change. > There've been a very few exceptions here and there over the years, but > simply eliminating group IDs en masse. That's close to closing down > the central repository completely. > > > 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. > > > > True enough, but a Java 8 jar can still have an explicit module name. > It's just one more entry in the MANIFEST.MF that pre-9 VMs are happy > to ignore. We can't go back and add module names to old jars but it's > worth adding explicit module names in new versions going forward. > > -- > 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.
