https://gradle.com/ logo
Join Slack
Powered by
Ahead of OSSRH deprecation (tomorrow), I have just...
# community-news
m
Ahead of OSSRH deprecation (tomorrow), I have just released the first RC of nmcp for your Maven Central publishing needs: https://github.com/GradleUp/nmcp/releases/tag/v1.0.0-rc.0
🙌 3
If you try it out, I'm curious to hear how that went for you!
v
Other accounts can continue publishing to OSSRH the usual way until June 30th 2025.
They can continue to use it, they just need to use a different URL. :-)
m
Thanks. That was written before the Portal OSSRH staging API was added. I have edited the wording.
👌 1
o
Yes, we had to adjust https://cookbook.gradle.org/integrations/maven-central/publishing/ too. Note that it still needs modification of the build file
j
Please have a look at this feedback: https://github.com/GradleUp/nmcp/issues/125
🙏 1
m
Thanks, I'll fix the plugin marker!
🙏 1
Re: the zip file, it's always a tradeoff!
Our publication right is ~40MB, not huge but not small either
If every plugin starts copying and snapshotting 40MB files around, this is how we end up with long builds
Now, it might be acceptable for the publishing because this is something that runs mostly in CI so I don't mind putting back the zip back
Just before doing that, there is 
NmcpAggregation.allFiles
that I have been using programmatically for other purposes.
It contains the exact zip contents (but not the metadata obviously)
So you could add your checks there, as a sibling tasks (i.e. not as a dependency of the upload)
Is that something that could work?
Obviously, it doesn't capture funky stuff like zip timestamps being inconsistent
And you'd had to trust that it's 1:1 the same content, i.e. the check is not on the critical path anymore, which I agree, is slightly less satisfying
FWIW, no strong opinion here, playing the devil advocate a bit to get to the bottom of the use case but I think it's fine to put the zip back
j
Thanks for the quick response and the context for the change. In the issue I also wanted to provide some context for why I think it would be a good thing (for certain users) to be able to check what exactly is uploaded, before it is uploaded. I don't have any critical checks in place right now (but maybe something interesting for the future). What I was relying on now was that I can call "do something" locally: • without having any credentials for Maven Central configured (because I don't have them) • see what will be uploaded in the next step that only runs on CI and has the credentials
NmcpAggregation.allFiles
Thanks for the hint! That's helpful right now I think
but I think it's fine to put the zip back
Would it be possible to make it configurable? So users can decide what is more important for them (saving disc space vs being able to inspect what is uploaded). Or would that create too much maintenance overhead?
m
Ahah yes, the setting is always the ultimate way to not settle a tradeoff 😄
What about we add the zip back, the time for everyone to build trust into the new portal, the plugin, etc...
And in v2, once everyone publishes with confidence we open an issue to zip in-memory?
And re-evaluate then?
Maybe in 1-2 years time? When we also have sigstore support 🤓 ?
j
I have no objections. 🙂 As I would lean towards that as the better default in this case despite the "extra space" tradeoff.
👍 1
m
Agreed 🤝. I think performance is a lot less important in publishing because it's not part of the "code-compile-eval" loop for most users
👍 1
I'll add the zip back and push 
rc.1
a bit later today
❤️ 1
j
I am not so much concerned with the "extra space". As ideally in a project I would create exactly 1 zip and that would be the software I produce. And I don't really see it as an intermediate result. It is the result. And the uploading is the deployment of the result. But it is probably a question of perspective....
In any case thanks so much for the quick response and good discussion @Martin!
m
Sure thing, thanks a lot for the feedbacks ❤️ !
Out of curiosity, does anyone in this thread has an opinion on whether zip files should contain directory entries or not? Looks like the portal API is happy with both? Are there any advantages/disadvantages to including them?
v
In the past I hit one case so far where I have seen this relevant. When building a deb package, Debian-based systems (at least many years ago that was the case) failed to install the package if there were no directory entries in the data 
.tar.gz
. 🤷‍♂️
👀 1
m
👍 
rc.1
will include them, it can run on debian! 😛
🐧 1
@Jendrik Johannes Using the zip task, I can verify that the plugin marker is correct before actually publishing the release 🎉
Copy code
$ unzip aggregation.zip
Archive:  aggregation.zip
  inflating: com/gradleup/nmcp/aggregation/com.gradleup.nmcp.aggregation.gradle.plugin/1.0.0-rc.1-SNAPSHOT/com.gradleup.nmcp.aggregation.gradle.plugin-1.0.0-rc.1-20250630.124731-1.pom
😃 1
👍 1
p
In my plugin, I did the lazy way and registered a local maven repo for the publication (using maven publish) and zip that folder (without the metadata.xml). So the resulting zip does contain the directories and central is okay with it. The whole implementation is quite simple just a few lines…
m
@Philip W most of the value (and code) of 
nmcp
is for snapshots. So that the credentials API can be the same for both the releases and snapshots (and also be CC-compatible)
p
Yeah, snapshots are „annoying“, because it is a different api, but on the other hand, you can reuse the maven-publish plugin for snapshots with the downside of having two different gradle tasks and credentials.
m
Yea, exactly. The 90% 
nmcp
implementation was really simple. And then came the

"other 90%"▾

😅
😄 1
v
Or you also reuse the traditional 
maven-publish
way for the production releases 🙂
m
@Vampire do we have commitment from Sonatype how long that will stay?
v
I have no idea, but I would hope it came to stay. In the beginning they did not have it at all until enough users complained and they added beginning of the year.
🤷‍♂️
If everyone uses that interface and only a few the new APIs, that might be a strong sign for them to continue supporting it. If only few use it, probability is higher it will be gone at some point I guess.
m
Yea... I hope this will all consolidate to a single API ultimately 🤞
Whichever it is, no strong preference there. The old one could be amortized during build. The new one is a bit more atomic. Different tradeoffs
p
Oh, wasn’t aware of the backporting with maven-publish support. I just noticed, publishing snapshots via maven-publish is way slower because Gradle uploads the files of each project sequentially, but I upload each release publication in parallel (I don’t do any root project aggregation). Maven publish (snapshots) takes 30 minutes, vs 5 minutes for a release.
😱 1
And yeah, I will file a bug at Gradle
m
I was expecting the opposite?
maven-publish
uploads file by file so you could theorically run projects in parallel and inside each project, artifacts in parallel
double the parallelism?
v
Maybe if you enable configuration cache so that the tasks can run in parallel?
➕ 1
p
Maybe the snapshot server are also slower 🤷🏻‍♂️
🤷 1
v
Quite possible
p
At least I get the same duration for the GitHub packages maven repo too…
Well, this is the snapshot run: https://gradle.com/s/la426pigkk736 based on https://github.com/hfhbd/kfx/actions/runs/16010218930 and this is the (now running) release run: https://github.com/hfhbd/kfx/actions/runs/16024268233/job/45208262135 Will add the build scan in a few minutes
CC is enabled, IP not (looking at you KGP)
v
You use IP in production? You are pretty brave. 😄
🚀 1
p
If possible, yes :D
💪 1
m
"Until proven otherwise, it works" 😄
Even CC has rough edges TBH but when it works, it saves time. (And when it doesn't it's a "fun" debugging exercise 😅)
p
m
snapshots 25min, release 6min?
Yikes for snapshots...
p
Yeah
v
Even CC has rough edges
Yeah, but it at least is declared stable and in latest versions even recommended by default. IP is declared as "pre-alpha" so highly experimental. 🙂
m
On the other hand, I'm guessing the snapshots server sees a lot more activity...
For both CC and IP I need to test for my specific build anyways. So if it works, might as well enable it. And if it doesn't, I can't use it, even if it's recommended 🤷
👌 1
But haven't had much success with IP lately so I kind of gave up there for now
p
Hm, maven-publish creates an upload task for each publication, while I create an upload task for each project bundling all project publications. But even the slowest snapshot upload takes 12 seconds, while the slowest release upload is about 2 seconds. Might be true the bottleneck are the servers, but it is still very slow... IMHO, maven-publish should also create a uber publication. But I will test maven-publish with a release in the next days.
👍 1
3 Views
Open in Slack
PreviousNext
Powered by