Ok thanks Tamas, I'll retract the PR then.
Best regards, Per On Fri, 8 Aug 2025 at 16:41, Tamás Cservenák <ta...@cservenak.net> wrote: > 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 > >
