Howdy, well MDK "failed" to get any traction (actually, people -1 on it), hence Njord: https://lists.apache.org/thread/t75bp7q1yvmgtn0s5zg7mjs2ofkdx7rk
For me, "Central Publishing" was always a very important topic, but for the rest of developers it seems it was not. Thanks T On Fri, Aug 8, 2025 at 4:36 PM Per Nyfelt <per.nyf...@nordnet.se> wrote: > > Hi Tamas, > > The MDK idea is a nice one (I did not know about it before). We can > absolutely move in that direction I think i.e. we could make the current > deploy and the central portal api two initial SPI implementations of a > generic deploy plugin. That requires some work though but I can give it a > try if you think that would be the right direction to go. > > Best regards, > Per > > On Fri, 8 Aug 2025 at 16:12, Tamás Cservenák <ta...@cservenak.net> wrote: > > > Howdy, > > > > Per, frankly I don't see why this would be done in m-deploy-p _directly_: > > - it is not a "good fit" anyway > > - why would we support in a core plugin anything proprietary? > > - what happens if tomorrow deployment protocol happens to change? > > (solution is not scalable nor pluggable) > > - from this (push all code into poor deploy plugin), I think MDK was > > one step better: https://github.com/maveniverse/mdk where the idea was > > to add SPI to m-deploy-p (with default/current one being pulled as > > dependency by the plugin), and then core extensions could swap out SPI > > implementations with own solutions, like the MDK extension was doing, > > or the mdk-jreleaser that simply plugged in jreleaser (preconfigured > > from Maven). > > - Also, if m-deploy-p gets support for Sonatype Central Portal, the > > question will arise: why then no support for nx2, nx3, Jfrog AF etc? > > As many repo/package SaaS offered, as many "protocols" may exist. > > Hence, pluggability is a key for me. > > > > So for me this whole experiment does not make a lot of sense. > > > > T > > > > > > On Fri, Aug 8, 2025 at 3:08 PM Per Nyfelt <per.nyf...@nordnet.se> wrote: > > > > > > I should add that I targeted the maven-deploy-plugin-3.x > > > < > > https://github.com/apache/maven-deploy-plugin/tree/maven-deploy-plugin-3.x > > > > > > branch. > > > Once (if) this has been vetted and approved I aim to create a mergeable > > > version for the master branch. > > > > > > Regards, > > > Per > > > > > > On Fri, 8 Aug 2025 at 14:56, Per Nyfelt <per.nyf...@nordnet.se> wrote: > > > > > > > PR submitted here: > > https://github.com/apache/maven-deploy-plugin/pull/612 > > > > > > > > Comments would be most welcome! > > > > > > > > Best regards, > > > > Per > > > > > > > > On Thu, 31 Jul 2025 at 22:57, Per Nyfelt <p...@alipsa.se> wrote: > > > > > > > >> I added support for mega bundles and also integrated tighter with the > > > >> DeployMojo. > > > >> > > > >> I changed deployAtEnd to default to true and added the property > > > >> useCentralPortalApi that also defaults to true (set both to false for > > > >> current deploy functionality) > > > >> > > > >> In my test project > > > >> (https://github.com/perNyfelt/maven-central-publishing-example) I set > > > >> autodeploy to false: > > > >> > > > >> <plugin> <groupId>org.apache.maven.plugins</groupId> > > > >> <artifactId>maven-deploy-plugin</artifactId> > > > >> <version>3.1.5-SNAPSHOT</version> <configuration> > > > >> <autoDeploy>false</autoDeploy> </configuration> </plugin> > > > >> > > > >> and did > > > >> > > > >> `mvn clean deploy` > > > >> > > > >> Which successfully deployed the mega bundle to central: > > > >> > > > >> se.alipsa.maven.example-1.0.0-bundle.zip > > > >> VALIDATED > > > >> Deployment ID: 66f0b1f1-5d59-4b33-ad00-5c6e7b700b9b > > > >> Created 16 seconds ago > > > >> Component Summary > > > >> 5 out of 5 Components Validated > > > >> pkg:maven/se.alipsa.maven.example/publishing-example-subA@1.0.0 > > > >> pkg:maven/se.alipsa.maven.example/publishing-example-common@1.0.0 > > > >> pkg:maven/se.alipsa.maven.example/publishing-example-parent@1.0.0 > > > >> ?type=pom > > > >> pkg:maven/se.alipsa.maven.example/publishing-example-parent@1.0.0 > > > >> pkg:maven/se.alipsa.maven.example/publishing-example-subB@1.0.0 > > > >> > > > >> I'll do some more cleanup and polishing and then create a PR where we > > > >> can continue the discussion... > > > >> > > > >> Best regards, > > > >> > > > >> Per > > > >> > > > >> On 7/31/25 10:22, Per Nyfelt wrote: > > > >> > Thanks for taking a look at this! Comments inline below: > > > >> > > > > >> > On Wed, 30 Jul 2025 at 19:20, Hervé Boutemy<hbout...@apache.org> > > wrote: > > > >> > > > > >> >> thanks for sharing this step: useful to study simple code > > > >> >> > > > >> >> > > > >> >> forcing user to do "mvn install myplugin:mygoal" instead of "mvn > > > >> deploy" > > > >> >> is > > > >> >> cheating :) > > > >> > notice that it opens an idea: Sonatype plugin could be used that > > way, > > > >> that > > > >> >> would be less tricky inside Maven, that could work with Maven 4 > > > >> >> > > > >> >> but I really hoped that we could do something in deploy:deploy > > that is > > > >> >> bound > > > >> >> to the deploy phase > > > >> >> > > > >> >> I agree but as an initial attempt, I wanted to isolate it. > > > >> > We can absolutely integrate it closer to make it happen when we do > > maven > > > >> > deploy. Should the current deploy still work as is and we add an > > extra > > > >> flag > > > >> > to determine which "mode" we publish with or should we change the > > way > > > >> > deploy works to only use the new publish process? > > > >> > > > > >> > > > > >> >> on uploading module (sub-project) per module, it's definitively a > > no > > > >> go: > > > >> >> having > > > >> >> 10s or even 100s of modules happens a lot, we need to do a single > > > >> bundle > > > >> >> = what the existing deployAtEnd option prepares quite well for > > > >> >> > > > >> > Yes, I am working on a mega bundle using exactly that logic. There > > is a > > > >> > size limit on the bundle of 1 GB so I think it would be useful to > > have > > > >> the > > > >> > "deploy each module separately" as an option. > > > >> > > > > >> > > > > >> >> > > > >> >> reading the code, I finally understood one key aspect: > > > >> >> we need to create a bundle, that one I knew > > > >> >> but what I got is that the bundle is not PUT like deploy usually > > does > > > >> with > > > >> >> http: it is POSTed > > > >> >> > > > >> >> so in addition to adding an option to create a bundle instead of > > > >> deploying > > > >> >> each file separately, we'll also need to add an option to not PUT > > file > > > >> but > > > >> >> HTTP > > > >> >> POST, with url and all Maven Central-specific data being in POM > > > >> >> distributionManagement > > > >> >> > > > >> > Yes, it's not even the common "post with attachment" but post as > > > >> > multipart... > > > >> > We already have the url param in distribution management and the > > > >> > username/token is retrieved from the settings based on the id so > > that is > > > >> > all good. The question is if we want > > > >> > a parameter in distributionmanagement or in the plugin config to > > give > > > >> the > > > >> > user an alternative to deploy as it works today or deploy using the > > new > > > >> > central api? > > > >> > > > > >> > Best regards, > > > >> > Per > > > >> > > > > >> > > > > >> >> > > > >> >> I'm sure it is feasible, I just did not have time to dive in > > > >> deploy:deploy > > > >> >> code sufficiently yet... > > > >> >> > > > >> >> Le lundi 28 juillet 2025, 21:52:55 CEST Per Nyfelt a écrit : > > > >> >>> Hi, > > > >> >>> > > > >> >>> I have a proof of concept working here: > > > >> >>> > > > >> >> > > > >> > > https://github.com/perNyfelt/maven-deploy-plugin/tree/add_central_support > > > >> >>> (the code can be much better integrated with the existing plugin, > > this > > > >> >>> is just a PoC). > > > >> >>> > > > >> >>> I used it to successfully uploaded and validate this project to > > > >> central: > > > >> >>> https://github.com/perNyfelt/maven-central-publishing-example > > > >> >>> > > > >> >>> using ` mvn -DautoDeploy=false clean install deploy:publish` > > > >> >>> > > > >> >>> (the autodeploy flag is set to false so it only does the upload > > and > > > >> >>> waits at central for an action i.e. to be dropped or published > > > >> manually) > > > >> >>> > > > >> >>> There is also a bundle step that creates the zip and also does > > some > > > >> >>> validation (so you don't have to actually try to upload the > > bundle to > > > >> >>> central to get feedback) that can be invoked separately with ` mvn > > > >> >>> -DautoDeploy=false clean verify deploy:bundle` > > > >> >>> > > > >> >>> Anyway, the deploy:publish deploys 4 bundles to central: > > > >> >>> > > > >> >>> 1. The aggregator project containing the pom (+ asc, md5, sha-1 > > and > > > >> >> sha-256) > > > >> >>> 2. common containing jar, source, javadoc and pom (+ asc, md5, > > sha-1 > > > >> and > > > >> >>> sha-256) > > > >> >>> > > > >> >>> 3. subA (that depends on common) containing jar, source, javadoc > > and > > > >> pom > > > >> >>> (+ asc, md5, sha-1 and sha-256) > > > >> >>> > > > >> >>> 4. subB (that depends on common) containing jar, source, javadoc > > and > > > >> pom > > > >> >>> (+ asc, md5, sha-1 and sha-256) > > > >> >>> > > > >> >>> I will see if i can add an support for the "deployAtEnd" flag to > > > >> create > > > >> >>> a mega-bundle instead and upload that. > > > >> >>> > > > >> >>> One thing that i found a little tricky is that we don't deploy the > > > >> >>> effective pom but rather the original pom (at least that's the one > > > >> that > > > >> >>> is signed so that's the only readily available choice) and the > > central > > > >> >>> validation rules requires the license, developer, description and > > scm > > > >> >>> sections to be present. In the effective pom these are inherited > > from > > > >> >>> the parent but the validation logic in central does not care about > > > >> that > > > >> >>> and rejects the deploy unless they are explicitly present. Maybe > > the > > > >> >>> validation will work differently in the mega-bundle. I'll will > > > >> >>> investigate... > > > >> >>> > > > >> >>> Best regards, > > > >> >>> > > > >> >>> Per > > > >> >>> > > > >> >>> On 7/22/25 19:16, Hervé Boutemy wrote: > > > >> >>>> one first step we could try could be adding a "deployToBundle" > > > >> >> parameter > > > >> >>>> to the deploy plugin, that would trigger an "at end" behaviour > > that > > > >> >> would > > > >> >>>> build a zip with all the deferred files, instead of copying each > > file > > > >> >>>> separately > > > >> >>>> > > > >> >>>> then see how just sending the bundle to the target (file: or > > https: > > > >> or > > > >> >>>> scp: or ...) would do the job > > > >> >>>> > > > >> >>>> this could be a minimalistic approach, that would have the > > benefit of > > > >> >>>> showing "bundle vs individual deploy" approaches > > > >> >>>> > > > >> >>>> > > > >> >>>> njord is that approach on steroids = really manage a local > > staging > > > >> area > > > >> >>>> (or name it as you want) and decide in a separate plugin where > > to put > > > >> >> the > > > >> >>>> staging area content and in which detailed format (PUT individual > > > >> >> files, > > > >> >>>> send everything as a unique archive, split the archive in smaller > > > >> ones, > > > >> >>>> or any future strategy)> > > > >> >>>> On 2025/07/22 12:14:28 Per Nyfelt wrote: > > > >> >>>>> It CAN be deployed as a single zip but it does not have to be. > > The > > > >> >>>>> downside > > > >> >>>>> of deploying each module separately is that if one deployment > > fails > > > >> >> then > > > >> >>>>> you end up with a "partial" deploy (from the point of view of > > the > > > >> >> whole > > > >> >>>>> project) but I think you only end up in this situation in the > > > >> >> beginning > > > >> >>>>> when you have not configured everything properly. If we do > > internal > > > >> >>>>> validation first (check that an asc, md5 and sha1 accompanies > > each > > > >> >>>>> artifact) then this kind of error can be eliminated. What > > remains > > > >> >> would > > > >> >>>>> then be network errors in which case you would just deploy the > > > >> failed > > > >> >>>>> module again. > > > >> >>>>> > > > >> >>>>> Regards, > > > >> >>>>> Per > > > >> >>>>> > > > >> >>>>> On Tue, 22 Jul 2025 at 13:25, Guillaume Nodet<gno...@apache.org > > > > > > >> >> wrote: > > > >> >>>>>> And I think that's exactly the problem as the deployment needs > > to > > > >> be > > > >> >> a > > > >> >>>>>> single zip file IIUC. > > > >> >>>>>> > > > >> >>>>>> Guillaume > > > >> >>>>>> > > > >> >>>>>> Le mar. 22 juil. 2025 à 12:28, Per Nyfelt< > > per.nyf...@nordnet.se> a > > > >> >>>>>> écrit > > > >> >>>>>> > > > >> >>>>>>> Hi Tamas, > > > >> >>>>>>> > > > >> >>>>>>> I think it would work. Each part is zipped up and deployed > > e.g. > > > >> >>>>>>> assuming > > > >> >>>>>>> you have a multimodule project like this: > > > >> >>>>>>> Aggregator > > > >> >>>>>>> > > > >> >>>>>>> - common > > > >> >>>>>>> - subA (depends on common) > > > >> >>>>>>> - subB (depends on common) > > > >> >>>>>>> > > > >> >>>>>>> Deploying all of this would mean 4 zip files are created and > > > >> >> published > > > >> >>>>>>> 1. The aggregator is just the pom (+ asc, md5 and sha1) > > > >> >>>>>>> 2. common is the pom, jar, javadoc and sources (all signed and > > > >> with > > > >> >> md5 > > > >> >>>>>> and > > > >> >>>>>> > > > >> >>>>>>> sha1 files) > > > >> >>>>>>> 3. subA is the pom, jar, javadoc and sources (all signed and > > with > > > >> >> md5 > > > >> >>>>>>> and > > > >> >>>>>>> sha1 files) > > > >> >>>>>>> 4 subB is the pom, jar, javadoc and sources (all signed and > > with > > > >> md5 > > > >> >>>>>>> and > > > >> >>>>>>> sha1 files) > > > >> >>>>>>> > > > >> >>>>>>> That should work fine i think or am i missing something? > > > >> >>>>>>> > > > >> >>>>>>> Regards, > > > >> >>>>>>> Per > > > >> >>>>>>> > > > >> >>>>>>> On Tue, 22 Jul 2025 at 11:13, Tamás Cservenák< > > ta...@cservenak.net > > > >> > > > > >> >>>>>> wrote: > > > >> >>>>>>>> Per, > > > >> >>>>>>>> > > > >> >>>>>>>> You cannot publish to central using plugin bound to > > lifecycle as > > > >> it > > > >> >>>>>> will be > > > >> >>>>>> > > > >> >>>>>>>> invoked in every module/subproject... Portal needs "at end; > > all > > > >> >>>>>> artifacts" > > > >> >>>>>> > > > >> >>>>>>>> kind of operation and Maveniverse Njord does that without > > > >> >> interference > > > >> >>>>>> to > > > >> >>>>>> > > > >> >>>>>>>> your build. > > > >> >>>>>>>> > > > >> >>>>>>>> Maven4 has improved lifecycle with "after:all" but Maven3 > > does > > > >> >> not, it > > > >> >>>>>>>> needs a bit more. > > > >> >>>>>>>> > > > >> >>>>>>>> T > > > >> >>>>>>>> > > > >> >>>>>>>> On Tue, Jul 22, 2025, 11:07 Per Nyfelt<per.nyf...@nordnet.se > > > > > > >> >> wrote: > > > >> >>>>>>>>> Hi, > > > >> >>>>>>>>> How about adding a deployToCentral (or similar) goal to the > > > >> >>>>>>>>> maven-deploy-plugin that uses the new API so that this is > > > >> >> supported > > > >> >>>>>>>>> "natively"? > > > >> >>>>>>>>> I would be willing to implement it if you think it's a good > > > >> idea. > > > >> >>>>>>>>> > > > >> >>>>>>>>> Regards > > > >> >>>>>>>>> Per > > > >> >>>>>>>>> > > > >> >>>>>>>>> On Tue, 22 Jul 2025 at 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-m > > > >> >>>>>> aven-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 > > > >> >>>>>> -- > > > >> >>>>>> ------------------------ > > > >> >>>>>> Guillaume Nodet > > > >> >>>>>> > > > >> >>>>>> > > > >> --------------------------------------------------------------------- > > > >> >>>>>> 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
