Jeremy, Just to be clear, you are not in the "vanilla" space, as you are using a vendor plugin/extension, right?
On Wed, Apr 30, 2025, 18:26 Jeremy Landis <jeremylan...@hotmail.com> wrote: > 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 > >
