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