I think someone should reread the mail :)
Yes, many publishing tools have been out there for quite some time,
but they are "out of Maven" as you say, and usually they reinvent
their own universe as well.
But, just like MDK _did integrate_ JReleaser (did you check out MDK?),
nothing stops Njord to provide 5th publisher that is "Jreleaser
powered", aside of existing 4 ones (apache-rao, sonatype-oss,
sonatype-s01 and sonatype-cp). Also, if I remember correctly, I even
mentioned this to Andres on Maven Slack.
Still, just like in MDK times, I feel JReleaser is a bit "too much",
too heavyweight and doing way too much for this purpose (Maven
prepares all, no need for signing, hashing, assembling, checksumming,
assembling, etc).
On Wed, Apr 30, 2025 at 5:37 PM Benjamin Marwell <bmarw...@apache.org> wrote:
>
> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
