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 > >
