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 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 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 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> > >>> > >>> 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 <[email protected]> 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 <[email protected]> > >>> > >>> 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 < > >>> > >>> [email protected]> > >>> > >>>>>>> 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 < > >>>>>> > >>>>>> [email protected]> > >>>>>> > >>>>>>>> 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: [email protected] > >>> > >>>>>>>>>>>> For additional commands, e-mail: > >>> [email protected] > >>> > >>> --------------------------------------------------------------------- > >>> > >>>>>>>>>>> To unsubscribe, e-mail: [email protected] > >>>>>>>>>>> For additional commands, e-mail: [email protected] > >>>>>> > >>>>>> --------------------------------------------------------------------- > >>>>>> > >>>>>>>>>> To unsubscribe, e-mail: [email protected] > >>>>>>>>>> For additional commands, e-mail: [email protected] > >>>>> > >>>>> --------------------------------------------------------------------- > >>>>> > >>>>>>>>> To unsubscribe, e-mail: [email protected] > >>>>>>>>> For additional commands, e-mail: [email protected] > >>> > >>> --------------------------------------------------------------------- > >>> > >>>>>>>> To unsubscribe, e-mail: [email protected] > >>>>>>>> For additional commands, e-mail: [email protected] > >>> > >>> --------------------------------------------------------------------- > >>> > >>>>>>> To unsubscribe, e-mail: [email protected] > >>>>>>> For additional commands, e-mail: [email protected] > >>> > >>> -- > >>> ------------------------ > >>> Guillaume Nodet > >>> > >>> --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: [email protected] > >>> For additional commands, e-mail: [email protected] > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
