On 2025/07/06 12:36:02 Jon Harper 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 ?
Worst BS approach I have ever seen for an OSS ecosystem w/o having the code for the deployment not using standard plugins. I don't understand why Sonatype reinvented the wheel and had to make like so complicated. This will scare off even more people. M --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
