Howdy, Cool that you brought up this topic, thanks! Well, for start, to not repeat myself, a bit of history: https://maveniverse.eu/blog/2025/07/02/pom-proliferation-part-1/ (note: this is in fact a response to completely unrelated blog entry, but is good to "cover the grounds" for now)
In short: what today happens with Maven Central (MC) is totally out of scope of ASF Maven Project, that created it. What I also find ironical (or sad) is that project "causing" MC lost native access to it (while with Nx2 ran OSS/S01 you could use m-deploy-p just fine, from now on, you cannot). Hence, there is no "native" or "out of the box" support for publishing for Maven right now. As you know, there are some solutions offered, that are all problematic for me as well: - they either "reinvent" (or force you to) reconfigure whole world again - or meddle with your build and have different requirements you need to implement Hence, the thing I'd recommend from maveniverse is Njord: https://maveniverse.eu/docs/njord/ That basically (re) implements what Nx2 had, but locally and adds publishing support as well. This extension was done to fully container all the issues above: - is not "aggressive", literally steps aside - does not require to reconfigure your whole build (you can publish even non integrated projects with it) - uses Maven and is Maven "native", no parallel worlds Of course, Njord does not help with cases like TrinoDB has (that is Central Portal server side limitation), and many other things, but is working for many other projects. Also, as you mentioned, I created this issue (as Njord suffers from it as well): https://github.com/maveniverse/njord/issues/150 HTH Tamas On Sun, Jul 6, 2025 at 2:37 PM Jon Harper <jon.harpe...@gmail.com> wrote: > > Hi everyone, > I think it would be very beneficial for the community that the maven > dev team communicates on the current events of the sunset of OSSRH. > Otherwise, I think there is a big risk of uncertainty and division in > the community. > > Quoting Romain ( > https://lists.apache.org/thread/bf3762lvd8l64hwyny7rnp3m6r852b9h ) > from a year ago > "most of us using central outside the asf will be impacted sometime > next year probably" > > And now this time has come (note: I shamefully procrastinated the > ossrh migration until I was forced to, but like many people I > guess..). Unfortunately, it coincides with the last stages of the > maven 4 release, so I understand that everyone is very busy at the > moment. > > Maven is a tool that communicates with the outside world, so I would > think it's legitimate for the maven devs to publicly express their > guidelines. Unfortunately it's not an easy task (as a matter of fact, > the best resource I currently know for this is the personal blog of > Karl Heinz Marbaise), but maybe an email discussion can lay enough > foundations by gathering many opinions so that a coherent message can > be sent to the community ? > > Aggravating factors in central-publishing-maven-plugin that lead to > uncertainty according to me: > - Similarity with the standard maven-deploy-plugin. Sonatype even has > a compatibility service but its use is discouraged ("We hope that over > time plugins will adopt the Portal API rather than rely on this > service" in > https://central.sonatype.org/publish/publish-portal-ossrh-staging-api/ > ). > - No public scm system available makes it hard to get context > information ( > https://repo1.maven.org/maven2/org/sonatype/central/central-publishing-maven-plugin/0.8.0/central-publishing-maven-plugin-0.8.0.pom > lists https://github.com/sonatype/central-publishing-maven-plugin but > is 404). (Note: The code is still available in the source jar > alongside the plugin > https://repo1.maven.org/maven2/org/sonatype/central/central-publishing-maven-plugin/0.8.0/central-publishing-maven-plugin-0.8.0-sources.jar > ) > - central-publishing-maven-plugin uses <extension>true</extension> to > forcefully remove any invocation of the maven-deploy-plugin which I > found surprising (aggressive ?) behavior. > - impossible as of 0.8.0 to use central-publishing-maven-plugin behind > a corporate proxy which ( by virtue of the http client5 of apache > httpcomponents without the extra code required to allow proxies ...) > - looks like fighting instead of cooperating (even though the plugin > architecture of maven invites this kind of work, maybe it's better > when core functionality stays within the maven umbrella like the > maven-deploy-plugin?) > > What are your thoughts ? Are the recent improvements to the > maven-deploy-plugin strong enough the try and unite all publishing > plugins as one ? > > 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
