FYI regarding deploy plugin I wanted to point out from personal experience on the migration.
maven deploy plugin still is used for snapshots per central documentation and I've been doing so for a few weeks now. Here is an existing action that is deploying to new central and still same deploy https://github.com/hazendaz/javabean-tester/blob/master/.github/workflows/sonatype.yaml The snapshot repository remains but as follows <snapshotRepository> <id>central</id> <url>https://central.sonatype.com/repository/maven-snapshots/</url> </snapshotRepository> Yes, the release one is gone and instead central-publishing-maven-plugin is used instead. One problem I ran into was with cyclonedx. Because on a physical release, the deploy plugin is taken over by the central publishing extension and cyclonedx relies on deploy, this flag was necessary `<skipNotDeployed>false</skipNotDeployed>` for cyclonedx to deploy during release. Outside of that, to enable snapshot usage, it requires toggling it on in the new central. I've not seen any other concerns in that regard post migration. I've migrated 11 group ids over and going through everything to ensure things are working as expected. - Jeremy -----Original Message----- From: Tamás Cservenák <ta...@cservenak.net> Sent: Wednesday, April 30, 2025 11:52 AM To: Maven Developers List <dev@maven.apache.org> Subject: Re: [DISCUSS] Publishing to Central + Maveniverse Njord 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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fiss > > ues.apache.org%2Fjira%2Fbrowse%2FMNG-8584&data=05%7C02%7C%7Ce8b3e297 > > 922e4bc5be6608dd87ff0c49%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0% > > 7C638816251683637328%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWU > > sIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3 > > D%7C0%7C%7C%7C&sdata=38Dx6ncp8iTMYqp%2BV0aKkdi35q57NDDUWj2vLJuLNvU%3 > > D&reserved=0 > > > > --- > > > > 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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit > > hub.com%2Fmaveniverse%2Fmdk&data=05%7C02%7C%7Ce8b3e297922e4bc5be6608dd87ff0c49%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638816251683668372%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=WnA3CzDvmltVThHU3RmVH7pbqELmhp%2Br2cfi0f8B7CU%3D&reserved=0 > > was deemed overly complicated (and spanning across several things), so it > > was dropped. > > > > Next attempt is Njord: > > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmav > > eniverse.eu%2Fdocs%2Fnjord%2F&data=05%7C02%7C%7Ce8b3e297922e4bc5be66 > > 08dd87ff0c49%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C6388162516 > > 83688053%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjA > > uMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C% > > 7C&sdata=p1SfF6SK7mPMb9wj81nphA8vzpQfQKsbfqlDH3KrfQ8%3D&reserved=0 > > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit > > hub.com%2Fmaveniverse%2Fnjord&data=05%7C02%7C%7Ce8b3e297922e4bc5be66 > > 08dd87ff0c49%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C6388162516 > > 83703538%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjA > > uMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C% > > 7C&sdata=HXqIe7PrrdvZuOQfsSaNXQhvtr3%2F1zhUKLLtmi4GRPI%3D&reserved=0 > > > > 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
