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
