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
