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
