I think we should also take a look at JReleaser.
It has been around quite a while, Andres is an excellent contact and maintainer.
Any reason why we should choose one of the two?
JReleaser moves the releasing process out of maven, which is a bit
sad. But it can be used as a plugin, too.
So maybe this would be a good solution, too?
- Ben
Am Mi., 30. Apr. 2025 um 17:18 Uhr schrieb Tamás Cservenák
<ta...@cservenak.net>:
>
> Howdy,
>
> As we know, we have changes upcoming regarding publishing to central
> (in short: oss/s01 are being sunset, Central Portal becomes the new
> service; if unsure what am talking about, please google it up). Also,
> while there were vendor and third-party plugins and solutions for
> this, I am talking about the "vanilla Maven experience" here.
>
> Maven aspect so far: all the "old" publishing services so far
> (OSS/S01/RAO) were based on Sonatype Nx2 "tech", that provided support
> for maven-deploy-plugin, basically allowing seamless use of these
> services from within Maven (doing `mvn deploy` just worked) at the
> cost of "pushing some buttons" as part of publishing workflow: you had
> to close and release the staging repository that service created for
> deploy, and the happy path was that after sync, we got artifacts
> published to Central.
>
> The new service is NOT maven-deploy-plugin friendly anymore. This
> makes Maven, the project that invented Central, become unable to
> publish to Central out of the box (again, "vanilla experience").
>
> To continue, let's introduce some terminology to have all of us on the
> same page:
>
> * deploy(ing) - is what Maven always did (maven-deploy-plugin): it is
> "uploading artifacts (one by one, request-wise) to some remote
> location", by default it happens "interleaved as subproject lifecycle
> runs" and it "edits" metadata as well. Later we introduced the "deploy
> at end" feature, but nothing fundamentally changed here: the artifacts
> are still deployed one-by-one, metadata handling is done by your
> Maven, and to have your deployment complete, the last subproject of
> the session must be deployed as well. Long time ago, when a remote
> repository was imagined as a httpd+webdav, or today w/ MRM hosted
> repository, this worked and works quite well.
>
> * publish(ing) - Since 2010 things have changed: many tools already
> use this term, and it is NOT the same thing as "deploying" or even
> "deploying with a twist": is not even close to it. Publishing usually
> has its own WORKFLOW, like explained above: get your payload there (in
> some form), then do something (push some buttons), maybe spawn a vote
> in between, and finally again do something (push some more buttons) to
> finally get your artifacts somewhere. Publishing usually requires
> handling your project output "as a whole", something not naturally
> mapped onto the project itself. Finally, there is no (at least when
> compared to deploy) much metadata requirement either, as "embedding"
> your output to its final resting place is done by the vendor providing
> the publishing service, as they have to, unless they want to end up
> with corrupted metadata. Finally, "publishing" as described above is
> not something Maven (3 or 4) is able to do today: so far all we had
> was some variation of "deploy with a twist"-like hacks instead.
>
> The new "publishing" involves two aspects:
>
> * target - is WHERE you publish, to keep things simple, usually we
> assume "target == Maven Central" but again, it could be anything (ie.
> corporate MRM w/ staging used to get artifacts to some corporate
> hosted repository). Targets also define the "requirements", like
> mandatory and optional checksums, signatures and so on.
>
> * service - is HOW you publish (basically a service implementing the
> workflow mentioned above). Usually service implies target (ie. using
> repository.apache.org you publish to Central) but does not have to.
> Service is operated by some vendor, usually is not open source and
> different services may require vastly different "ways" (protocols?) to
> publish, as there are no standards defined in this area.
>
> Today we have several services to publish, and they all end up on same
> target, Central:
> * repository.apache.org (apache-rao)
> * oss.sonatype.org (sonatype-oss, soon to be sunset)
> * s01.oss.sonatype.org (sonatype-s01, soon to be sunset)
> * central.sonatype.com (sonatype-cp, the new "Central Portal" service)
>
> In general, I'd propose the use of $vendor-$service naming to keep
> things clear (and unique and future proof). Overuse of "central" is
> just killing us, nor is it appropriate for any service, as it is the
> target.
>
> As said above, the sunset services are taking away the "native" Maven
> deploy support. Moreover, Maven 4 is here to come, but we cannot leave
> Maven 3 users alone either. In Maven 4 you can more easily hack up
> some "deploy with a twist" solution, but this does not work for Maven
> 3 users.
>
> Plus, I'd dare to say that publishing is something orthogonal to your
> project. What if you want to publish to two places? Or what if you are
> about to (or forced to) switch services you use for publishing? These
> changes should be "simple" (as in light, simple to implement), but
> instead, many times this imply quite a lot of changes on your project,
> introducing new profiles, properties, plugins, maybe extensions, and
> so on. Even if we consider the same target (Central), moving from one
> service to another is not trivial. So far, Maven "got away" by using
> (hence, changing) Nx2 staging endpoint in
> distributionManagement.repository.url (ie. when moving from S01 to
> RAO), but again, this is simply not enough today.
>
> Site note: many Maven projects used one of RAO, OSS or S01 to publish
> to central, and almost all of them used "own invented" server.id for
> authentication, even if it was pointing to the same service. User who
> was hopping from project to project had to fill up his settings.xml
> with all the variations of used server IDs for these 3 services, even
> if auth material was usually the same (as the user had own account on
> these). Hence, by separating service from POM. it would allow users to
> have only as many service related server entries in settings.xml as
> much they are really using (currently max would be 4).
>
> (a digression: IMHO distributionManagement.repository.url should
> contain the TARGET URL, not the SERVICE -- that may not even be
> describable with a single URL -- , but that's another thing and topic,
> not for this thread).
>
> Maven did a great job of abstracting things away ("everything is an
> artifact", "remote repository is from you get them" etc) hence WHERE
> and HOW you publish should be abstracted as well. In fact, nothing
> should stop you from publishing to two places as well. Who knows what
> the future brings?
>
> Hence, IMO we need to act in this area. We should:
> * provide OOTB solution for both, Maven 3 and Maven 4
> * have it non-invasive (as opposed to vendor supplied, closed source
> solutions) that poses requirements to alter/adapt your build AND ties
> you to one service
> * still, it should not reinvent the whole universe, it should rely on
> Maven infrastructure as much as possible (ie. user should not
> reconfigure the solution ground-up, or use alternate means to provide
> auth etc). It should be a Maven thing, not some side stuff.
>
> Users are concerned as well, for example, here is this issue, that
> nicely collects all the known problems, worth reading:
> https://issues.apache.org/jira/browse/MNG-8584
>
> ---
>
> So, after a long email, a short(er) proposal: as you may know,
> Maveniverse umbrella is the place for "fast paced prototyping and
> experiments", but it also hosts projects that our members voted to not
> have under the ASF Maven project (like Mason Maven4 extension is).
> There were several attempts to provide solutions for the problems
> above. The initial attempt named MDK
> https://github.com/maveniverse/mdk was deemed overly complicated (and
> spanning across several things), so it was dropped.
>
> Next attempt is Njord:
> https://maveniverse.eu/docs/njord/
> https://github.com/maveniverse/njord
>
> It is still prototyping, many things are not there yet, like automatic
> workflow handling (ie. publishing still happens as with RAO/OSS/S01
> service with "vanilla experience", like most ASF projects do: you need
> to push some buttons), but solves the problems explained above and
> also enables Maven 3 and Maven 4 to publish to the new Sonatype
> Central Portal without any hassle. Importantly, it is not invasive nor
> forces users to "reinvent" anything. As extra, it offers "local
> staging" (analog to Nx2 "remote staging") and much more.
>
> In short, with Njord:
> * to use it, you need no project change at all (!) -- ideally with
> Maven 4 it can be just "user extension", similar to Mimir
> * you can deploy "as usual", your project works as before, no need to
> change anything (but undoing "tricks" for current Central publishing
> is worth to do).
> * with it, you can locally stage the project as many times you want,
> it works with or without release plugin
> * once you have staged the artifacts, you can publish locally staged
> repositories (and drop it, or maybe keep it and re-publish it
> somewhere else, etc) and many more.
>
> So, I'd like to ask you to:
> * please take a peek at Njord, scrutinize it, propose improvements and
> changes for it, maybe even test drive it
> * if you want, fall in and help pushing it toward 1.0.0
> * and once (and if) we agree it is "done" (whatever it would mean),
> I'd like to propose to "bring it in" into the ASF Maven project, and
> make it some sort of "Maven 3/4 Solution for Publishing".
>
>
> Thanks
> T
>
> ---------------------------------------------------------------------
> 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
