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

Reply via email to