Hi Jon, That one is "transitional" solution and Sonatype itself states they hope will be used by projects while transitioning only. I'd not consider it as final solution.
T On Tue, Jul 22, 2025, 10:39 Jon Harper <jon.harpe...@gmail.com> wrote: > Hi Hervé, > thanks for looking into it. Did you try the sonatype compatibility > service ? > https://central.sonatype.org/publish/publish-portal-ossrh-staging-api > > Also, while the governance and roadmap of > central-publishing-maven-plugin is not open, the code itself is OSS > (uses the apache license v2 as indicated in the pom > > https://repo1.maven.org/maven2/org/sonatype/central/central-publishing-maven-plugin/0.8.0/central-publishing-maven-plugin-0.8.0.pom > ) > Cheers, > Jon > > On Sat, Jul 19, 2025 at 10:13 PM Hervé Boutemy <hbout...@apache.org> > wrote: > > > > deep dive done, with personal evaluation > > > > https://github.com/apache/maven-studies/tree/deploy > > > > happy to discuss and complete the review > > > > Le jeudi 17 juillet 2025, 03:53:40 CEST Hervé Boutemy a écrit : > > > I finally stopped procrastinating and took time to test > > > > > > https://github.com/apache/maven-studies/tree/deploy > > > > > > This does not yet give me a strong answer about what I personally would > > > choose to promote, but at least better understanding of the misc > options > > > > > > Le mardi 8 juillet 2025, 08:45:25 CEST Hervé Boutemy a écrit : > > > > 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 > > > > > > -m > > > > > > a > > > > > > 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 > > > > > > -m > > > > > > av > > > > > > > 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 > > > > > > --------------------------------------------------------------------- > > > 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 > >
