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