it seems we're back to Maven history of: 1. publication to simple file systems (eventually shared) 2. multi-module (aka. multi-subproject) publication 3. multi-file publication in a single gav
On the positive side, this has been very flexible and perfect for downloads. But on the negative side, this leads to quite undefined publication protocol, and misunderstood, even when we tried to share some doc https://maven.apache.org/repository/layout.html In the past, the complaint was that there was no "standard" REST API to publish (ignoring that REST did not exist when Maven was growing). Now there is a REST API with proper documentation https://central.sonatype.com/api-doc We could expect everybody to be happy, but no. We are discovering it is perfect for smaller publications. But it opens questions for bigger publications. And yes, we're still in a half undocumented mix of approaches (Maven-native per-file PUT vs REST API for publishing an archive vs how to split multi- module?) Reading Njörðr description https://maveniverse.eu/docs/njord/what-is-it/, it is a Maven Resolver Repository Connector, looks like a good integration in the native Maven CLI: please call it something like "Njörðr publisher" and I may remember what it does... I definitively need to dive into it: very interesting. And next spte will be to have a wider community understand all these concepts, as beginning of all the issues is that we're touching many in-depth aspects that are unknown to many. One additional TODO on my ever growing TODO list... Regards, Hervé Le lundi 7 juillet 2025, 16:48:39 CEST Tamás Cservenák a écrit : > 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-ma > > ven-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-mav > > en-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 --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
