https://kotlinlang.org logo
Join Slack
Powered by
Has anyone here been through the migration process...
# opensource
d
Has anyone here been through the migration process for their libraries from the Legacy Maven OSS to the new Central Publisher Portal? I'm really unclear as to if you can continue to publish , or even if the official gradle maven-publish plugin will even work with the new server. Oh and they're sunsetting the old system in June... https://central.sonatype.org/faq/what-is-different-between-central-portal-and-legacy-ossrh/
p
Haven't gone through it yet. They hadn't announced the shutdown date the last time I looked into it. (Announcement)
They explicitly say that they're won't be official gradle support until after the shutdown. So it seems to be a "pick from this collection of 15 options, good luck".
d
Yeah - that's how I read it. What a mess. This is going to affect everyone! Including jetbrains's OSS stuff presumably. Maybe we can get them to make some noise...
They explicitly say that they're won't be official gradle support until after the shutdown. So it seems to be a "pick from this collection of 15 options, good luck".
Thinking more about it - this is a significant risk to the security of the JVM open source ecosystem. Let's imagine a scenario: 1. They shut off publishing of OSS libraries to the legacy OSSRH on 30th June 2. A high risk CVE is found in a project that currently uses the gradle plugin. 3. But there is no support in Gradle using the official plugin for ??? time after 30th June. 4. The project in question have not been lucky enough to trip over this announcement in the mere 90-odd days Which means that in order to actually get a fix out, the OSS team need to both fix it AND migrate to a new release pipeline. And let's be honest - it wasn't exactly easy the first time around (at least for us) to get it working.
a
Happy to see I won't need to migrate. Huge pain to get it working; and then all over again to get it working for multi-module.
d
Eventually. You just need to be ok with the wait...
m
The announcement is really weird but I read it as "you can continue publishing on the old OSSRH but don't expect too much support there" (which isn't great but still gives more options I guess)
https://github.com/vanniktech/gradle-maven-publish-plugin is really good, the migration is not that bad with it
I also maintain https://github.com/GradleUp/nmcp/ if you're looking for something more lightweight. I'll happily address any feedback you have.
What makes me sad about all this is that the central portal doesn't show stats, or I didn't found how to read them...
d
Yes I noticed this - it's a massive oversight. We use those stats heavily
m
Yea, not only for marketing purposes but even technically, it's useful to know how fast people migrate, etc...
d
Thanks for the pointers. I was kind of expecting the gradle plugin to be ready... To me that's a must before they can consider turning it off
I actually read it differently... it says "expect less support as we get to the deadline"... Not past
m
Gradle doesn't want to do it and sonatype neither I think
I actually read it differently... it says "expect less support as we get to the deadline"... Not past
That might be it. Want to write to central-support@sonatype.com to ask for clarification? They are usually quite responsive
d
Yep - I can do that. But depending on their answer we might need to make some noise to apply pressure. I'm quite concerned about the security implications of projects 1. not being aware 2. gradle not wanting to update their plugin.
❤️ 1
m
Let us know what they reply!
s
@mbonnin thanks for developing/sharing nmcp! Do you have a reference project that deploys to new Central Portal using Kotlin + Dokka? Preferably using Github Actions? Thank you!
➕ 1
m
@Sami Eljabali sadly all my real world projects are still on the "old" OSSRH system. Mostly because of the aforementioned stats issue. We should probably migrate the GradleUp properties though, let me ask the team what they think about it.
d
This shows my major concern here - between gradle and sonatype they are probably expecting any OSS project (read unpaid volunteers) who use gradle to publish (this is a lot) to not only reintegrate with the new system but do it in just 90 days. And they haven't emailed anyone about this change (I only came across this by accident) or provided an official drop-in replacement (ie. just "replace this plugin with this one"). I just feel like bad stuff is going to happen the next time there is a large scale CVE problem and the team in question didn't know about this change.
(I've emailed central BTW - will post their reply in this channel)
🙏 1
m
FWIW, I don't mind the mandatory migration, it's a good thing IMO that we stop this system with 3 different backends for where to publish things and duplicate documention. I'm even okay with 90 days, it's a tad short but my hunch is that most of the people who don't update if given 3 months will not update more if given 1 year.
What I would definitely push for though is: • proper notice email for all users of OSSRH with a clear deprecation schedule (what is going offline when) • support for stats in the central portal
d
oh 💯 - I totally agree on those points. It's the lack of the standardised drop-in replacement and handwashing that is the real problem for me. if a log4shell2 CVE comes along - the situation is going to be made inexplicably worse if the project in question has not migrated. Mostly I want to give them a hard time 😉 ..
👍 2
s
@mbonnin would you be interested in helping me update my new Kotlin library to be a reference project for others? With compensation you for your time? Would be happy to write up a complimentary article too for the community. Thank you!
m
@Sami Eljabali sadly I don't have much time these days. Also, I'd say having a "reference" project is really hard due to the missing first party support.
s
No problem, thanks for your consideration Martin!
m
Sure thing!
d
As promised - the (rather encouraging actually!) response to my email from Sonatype Central:
thank you color 1
Copy code
Hello David, 
> There will be no official Gradle support (ie. Using the maven-publish plugin) for this new publishing mechanism as of the above date. Changing publishing mechanisms has been left at "please use one of these unofficial plugins" ([<https://central.sonatype.org/publish/publish-portal-gradle/](https://central.sonatype.org/publish/publish-portal-gradle/)>)  without any examples or support being provided. It seems that Gradle is also not treating this is an important issue: [<https://github.com/gradle/gradle/issues/28120#issuecomment-1954266992](https://github.com/gradle/gradle/issues/28120#issuecomment-1954266992)>.
 

To clarify, this particular point is where there is some miscommunication. We agree with you that Gradle support is important to a large percentage of the community and that it would cause significant issues to leave Gradle publishers without a way forward (and that it would exacerbate security issues). To address this, we created the [OSSRH Staging API](<https://central.sonatype.org/publish/publish-portal-ossrh-staging-api/>), which should allow you to point the built-in Gradle `maven-publish` plugin at a different URL, generate a Portal token instead of an OSSRH one, and add a single extra web request at the end of your build to indicate that your upload has completed and it should be propagated to the Portal (this is akin to manually logging in to the OSSRH UI and closing the repository or calling a dedicated Nexus Repository Manager 2 endpoint).  
   
The reason for this decision is that we wanted to have a publishing solution that could temporarily accommodate all publishers (Gradle, Maven, SBT, Bazel, etc.) while we worked both internally and with external partners such as Gradle to develop high-quality plugins that meet each ecosystem's needs. By decoupling that effort from the end-of-life of Sonatype Nexus Repository 2, we hope to buy ourselves more time to make the migration to the Portal a smoother experience.  
   
From the news article that you linked, we indicated  

> Once OSSRH is sunset, we will have more roadmap capacity to begin working on a first-party Gradle plugin. We are working with Sonatype's legal department to streamline the process of open sourcing Central-related plugins. This discussion is currently focused on our Maven plugin, but we intend to launch a first-party Gradle plugin as open source from day one.

We hope that you understand that we treat this as seriously as you do and we understand that the Gradle community in particular is an increasingly significant portion of publishers to Maven Central. 

> Tangentially, there are no download statistics at all available on the new central portal. This is a big problem for projects like ours which use the download statistics as a way of determining migration activities amongst other things. 
 
We're actively working on implementing stats for the Portal, but we are not comfortable giving a public estimate of when they will be available due to the cross-team collaboration with Sonatype's data team, who have their own priorities and initiatives. If you have a need for statistics in the meantime, please contact support and we can arrange a temporary solution.  
   
We would be interested in more information about what you mean by "determining migration activities" and what other ways the statistics are useful to your project. This would allow us to better understand the use-case(s) of statistics that any new solution would need to take into consideration,  
   
Thank you,  
The Central Team
💙 4
m
Always interesting to be reminded Gradle is the outlier build system in some parts of the world 😄
o
Thank you for sharing @dave. I cannot disclose the inter-company communications we've had with Sonatype. What I can say is there that we are taking care of the situation on our side though the communications didn't go smoothly on both sides (which resulted in these confusion and also us discovering the announcement post-factum). My plan is to have some official communication and guidelines from our side by mid-May
👍 1
n
In case you find it useful, I have a Kotlin+Gradle project that uses the new portal for publishing to Maven Central. https://github.com/nemecec/kotlin-logging-compile-time-plugin I have not integrated the publishing with CI (yet), I run it from command line:
Copy code
./gradlew -Dorg.gradle.daemon=false -Dkotlin.incremental=false clean publishToMavenCentral
It is based on @bnorm piecemeal project build system, I took that as an example and simplified it (maybe could be simplified even more). Piecemeal seems to release via a Github action. You can see from the build file that both projects use gradle-maven-publish-plugin from vanniktech — it was quite simple to set up.
🙌 1
n
i actually liked having the opportunity to manually review my publication before releasing the repository. in some cases, i would close and verify locally, via staging to make sure everything worked before releasing. does anyone know if this is still possible with the new API? i couldn’t find a way to see my bundle when using the existing maven plugin with the new URL and a valid token. the publish claimed to succeed, and i’m assuming it is waiting on the API call to close it. but i’d like to have a way to view what is about to be published to be certain ahead of closing for release. also, my login stopped working for https://oss.sonatype.org/ after i created a token. this sucks b/c it means i can’t even go back to that pathway in the interim while figuring out the migration.
m
opportunity to manually review my publication before releasing the repository
You can review the list of files in the central portal UI but not use it as a plain maven repo like you used to be able to with OSSRH
my login stopped working
Go to https://central.sonatype.com/api/auth/login and reset your password. Use that new password in OSSRH. This has worked for me in the past.
d
I also recently (last week) had a problem after logging on to the new portal that it locked me out of the old one (after setting a password). The reset worked for me and I can get back in.
n
strange. i reset my password and am able to login to Central as before. but i still can’t login to OSSRH with the new password.
d
Try and reach out to the support. They're actually really good. central-support@sonatype.com
➕ 1
n
i actually sent them an email. you’re right about them being helpful. they’ve answered other questions i’ve ask in a timely way. waiting to see what they suggest for this issue.
👍 1
o
For the information of anyone affected by the Maven Central announcement, this year we will have a Google Summer of Code project that will focus on Maven Central publishing in Gradle. Please welcome @Yongjun Hong, who will be working on the project! Given the announcements from Sonatype and multiple existing implementations, some alignment between maintainers and interested companies is needed. So, we created the 
#maven-central-publishing
channel on the Gradle Community Slack to coordinate the efforts: http://slack.gradle.org/. Everyone is welcome to join!
❤️ 2
🚀 1
n
That is expected, you can only login in Central Portal after migration.
seems like you are locked out from OSSRH the minute you initiate migration. so this explains why my login no longer works 😔
😲 2
o
So you need to migrate all your projects at once? Sounds fun (not so much)
d
You have to migrate each namespace at once, yes. We've got a monorepo with 180 modules... slightly worried tbh!
😟 1
m
Wait what? I still have a mix and match of ossrh, s01 and portal
I can still login to the different UIs.
But each namespace needs to go to a single destination indeed
m
I should probably do this, huh... How painful is it?
m
If you're using vanniktech's plugin it's a one line change
m
If you're using vanniktech's plugin it's a one line change
Beautiful... ❤️ I use it in all my projects I'm mainly concerned about the OSSHR migration process; have a lot of publications & snapshots...
m
It was pretty smooth for me. It is automated so it's probably "just" a click per namespace and then updating all your secrets everywhere
🎉 1
o
I started a very first draft of the publishing guidelines here - https://cookbook.gradle.org/integrations/maven-central/publishing/ . Contributions are welcome w.r.t support statuses, better guidelines, etc.
+ @louiscad given the Slack status 🙂
👀 1
thank you color 1
m
I asked central-support@sonatype.com about the download statistics, and got this reply:
In the process of sunsetting we are stopping support for stats until we are able to migrate the feature over to portal. We are unable to provide an accurate date on when this feature will arrive but we will be making it a priority shortly after the sunset date. we apologize for any inconvenience not having the statistics may cause.
So it looks like there will be a period when nobody has any statistics at all.
👀 2
n
a
Has anyone tried to get ossrh-staging-api to work with deployByRepositoryId with the pattern described here https://medium.com/kodein-koders/building-kotlin-multiplatform-with-github-actions-2478801d6d46 where a staging repo is created and then artifacts from multiple builds are placed inside. This pattern doesn't seem to work with ossrh-staging-api at all. Has anyone tried it? @romainbsl. I think the original medium article was yours. Have you tried using ossrh-staging-api ?
m
@Alexander Ioffe I contributed that code but you can forget about it now. Central Portal API doesn't have the concept of staging repo anymore
Which means if you publish from different machines, you'll have to publish different targets separately
It's breaking the atomicity of a KMP publication but also, there's no real reason to publish from different machines anymore as I think a single machine can publish all targets?
a
Really? Wouldn't it need to be OSX?
(ironically the 
<https://ossrh-staging-api.central.sonatype.com/service/local/staging/profiles/.../start>
API still works but it's impossible to use the output)
m
Copy code
To produce artifacts for projects with Apple targets, you'd normally need an Apple machine. However, if you want to use other hosts, set this option in your gradle.properties file
kotlin.native.enableKlibsCrossCompilation=true
(haven't tried it personnally, I use MacOS because it's just easier but that's an option)
a
Heh, I wonder if the same is true of the ming64 target 🤔
m
Report if you're trying it!
> It's breaking the atomicity of a KMP publication Actually, even if you cannot fit every target in a single zip, You may still upload 2 zips in 
USER_MANAGED
mode and then release both deployment from the portal UI. Once a deployment is validated, I have never seen it fail the "release" step so it's atomic in a way
a
Am I crazy or is this a gigantic fiasco that is about to happen? The endpoint 
<https://ossrh-staging-api.central.sonatype.com/service/local/staging/deploy/maven2/>
is completely awful for a KMP build because when you're doing many it's impossible to tell what Central staged artifact is coming from where. The IP-based isolation issue is an utter nightmare for anyone using github actions. Also, I can't build everything from a single-container because I've got the sqlite lib which is bonafide c-interop that I can go without.
Now as it turns out, the endpoint 
<https://ossrh-staging-api.central.sonatype.com/service/local/staging/deployByRepositoryId/$repositoryId/>
DOES actually work so long as you're working within the confines of the IP-based isolation. That is to say, you need to create the staging repo on the same github actions container (which is also annoying because you can't use 
nexus-actions/create-nexus-staging-repo
anymore) which you could do inside of gradle with some HttpClient calls.
Imaginably if you've got a build-logic target you can string-together some combination of Central calls that do 
/service/local/staging/profiles/$pid/start
and then 
manual/upload/repository/$REPO_ID_ENCODED?publishing_type=user_managed
but its a headache that every single KMP OSS maintainer is about to need to go through.
Specifically, this is a major issue with KMP builds because they've got reams of publishing targets that things like JReleaser don't support.
m
You need to stop thinking in terms of Nexus API, staging repos, etc... this is all going away
The new publisher API is at 
<https://central.sonatype.com/api/v1/publisher/>
and you upload a big zip there with one or several maven component
a
So what? We're back to the maven-assembly plugin days where we've got some shared-volume in the github tasks that we need to create ourselves? Isn't that a giant step backwards?
m
What do you mean by 
shared-volume
?
Something that you share between different CI workers?
a
Yeah, I'm stuck in docker-compose terminology
m
You need just one container to upload everything, no need to setup shared volumes
a
Right but again, I've got 3 builds that I can't get away from because I'm using a major c-interop lib. That means I've got to dump everything intermediately produced into some maven repo that's common to the single-upload container.
m
If you really really want to shard your publication, have different matchines upload the machines separately with 
USER_MANAGED
publishingType and then finalized them with a job that retrieves all the deploymentIds and publishes them (or drops them) all at once using https://central.sonatype.org/publish/publish-portal-api/#publish-or-drop-the-deployment
dump everything intermediately produced into some maven repo
Just use the portal API as the intermediate storage. It will hold your deployment until you finalize everything
a
Yeah, that's what I meant by 
manual/upload/repository/$REPO_ID_ENCODED?publishing_type=user_managed
That still means that I'm producing at least 3 artifacts instead of one
m
Yea, you now have 3 
deployments
instead of before a single 
staging repo
but really it should be similar.
There is a cool OSS project to do to do the 
nexus-actions
equivalent for the Publisher API
If anything, you might be able to save one job because you don't need the initial 
create-staging-repo
. On the other hand, each build job needs to output its 
deploymentId
a
This API that I mentioned 
/service/local/staging/profiles/$pid/start
actually creates the staging repo. That is what 
nexus-actions
does on the inside with either a CURL or some typescript code. Either way, this job is completely useless because it's keyed by the IP of the host and GitHub actions containers and the only useful way to invoke that is a common container at the beginning of the build.
Now you could technically invoke 
nexus-actions/create-nexus-staging-repo
inside of each matrix-build if you can capture its output.
m
No but really forget about staging repositories 😅
This is not a thing anymore
The only reason they still have it is to ease the transition but it's all going away
It's now going through the central portal. This is what I currently have for an example (don't pay attention to the red, this is not important 😄 )
What you need to do is 3 different deployments there.
a
Yeah, I saw this page
It feels extremely primitive compared to what s01.oss has
m
Well, I'm happy I don't have to deal with staging profiles or IP isolation anymore 🤷
The main drawback is that you can't amortize the upload during your build but since this is all happening in CI, I don't mind that much
That and stats are not there any more (but the team is working on it)
For the KMP sharded publications, it's functionally similar IMO. You don't have 
nexus-actions
anymore so someone needs to write the equivalent GitHub actions but this is all doable
a
I don't see how that's the case. You need some kind of assembly-plugin like thing to gather everything into one build if you're using a matrix. That's much more work than what 
nexus-actions
does. The 
nexus-actions
thing is literally a couple of curl calls. The 
create-nexus-staging-repo
is literally just this (here):
Copy code
jsonOutput=$(
  curl -s --request POST -u "$INPUT_USERNAME:$INPUT_PASSWORD" \
    --url ${INPUT_BASE_URL}staging/profiles/"${INPUT_STAGING_PROFILE_ID}"/start \
    --header 'Accept: application/json' \
    --header 'Content-Type: application/json' \
    --data '{ "data": {"description" : "'"$INPUT_DESCRIPTION"'"} }'
)
Even TheMrMilchmann's variation of it is just this (here):
Copy code
return await nexusRequest<NexusDTO<CreateStagingRepoResponseDTO>>(
        "POST",
        `/service/local/staging/profiles/${stagingProfileId}/start`,
        request
    ).then(it => it.data);
All of these things are tiny wrappers around Nexus's built in functionality
It's nexus that is doing all of the heavy lifting, not these scripts
m
Heavy lifting being keeping track of the 3 deployment ids?
Or is the objection that there are now 3 HTTP calls to make (1 for each deployment id)
I agree this is not as good cause if the second call fails, you end up in some weird state
a
My publish job looks like this:
Copy code
publish_command: >-
              :controller-core:publishMacosX64PublicationToOss
              :controller-core:publishMacosArm64PublicationToOss
              :controller-core:publishIosX64PublicationToOss
              :controller-core:publishIosArm64PublicationToOssRepository
              :controller-core:publishIosSimulatorArm64PublicationToOss
              :controller-core:publishTvosX64PublicationToOss
              :controller-core:publishTvosArm64PublicationToOss
              :controller-core:publishWatchosX64PublicationToOss
              :controller-core:publishWatchosArm32PublicationToOss
              :controller-core:publishWatchosArm64PublicationToOss
              :controller-native:publishMacosX64PublicationToOss
              :controller-native:publishMacosArm64PublicationToOss
              :controller-native:publishIosX64PublicationToOss
              :controller-native:publishIosArm64PublicationToOssRepository
              :controller-native:publishIosSimulatorArm64PublicationToOss
              :controller-native:publishTvosX64PublicationToOss
              :controller-native:publishTvosArm64PublicationToOss
              :controller-native:publishWatchosX64PublicationToOss
              :controller-native:publishWatchosArm32PublicationToOss
              :controller-native:publishWatchosArm64PublicationToOss
              :terpal-sql-core:publishMacosX64PublicationToOss
              :terpal-sql-core:publishMacosArm64PublicationToOss
              :terpal-sql-core:publishIosX64PublicationToOss
              :terpal-sql-core:publishIosArm64PublicationToOssRepository
              :terpal-sql-core:publishIosSimulatorArm64PublicationToOss
              :terpal-sql-core:publishTvosX64PublicationToOss
              :terpal-sql-core:publishTvosArm64PublicationToOss
              :terpal-sql-core:publishWatchosX64PublicationToOss
              :terpal-sql-core:publishWatchosArm32PublicationToOss
              :terpal-sql-core:publishWatchosArm64PublicationToOss
              :terpal-sql-native:publishMacosX64PublicationToOss
              :terpal-sql-native:publishMacosArm64PublicationToOss
              :terpal-sql-native:publishIosX64PublicationToOss
              :terpal-sql-native:publishIosArm64PublicationToOssRepository
              :terpal-sql-native:publishIosSimulatorArm64PublicationToOss
              :terpal-sql-native:publishTvosX64PublicationToOss
              :terpal-sql-native:publishTvosArm64PublicationToOss
              :terpal-sql-native:publishWatchosX64PublicationToOss
              :terpal-sql-native:publishWatchosArm32PublicationToOss
              :terpal-sql-native:publishWatchosArm64PublicationToOss
That's just one of them
I imagine I'm not the only KMP OSS guy in the same boat
Rolling that into a assembly-container is annoying to say the least
m
Use nmcp and call 
publishAggregationToCentralPortal
?
a
I don't see how that helps. I can't blindly do 
publishAllPublicationsToOss
on my OSX builds because that causes horror.
How does nmcp know what my aggregation is supposed to be?
Oh! I see it's this thing 
nmcpAggregation(project(":module1"))
m
Yes, that
a
Ah, okay. I see how I can get away from doing a staging repo for aggregation but it still doesn't get away from me needing to do 3 targets which I guess is better?
I don't know. I can't help but feel that all of this is a giant step backwards from what Nexus use to provide
Nexus had a real managed-lifecycle for maven publications. We're being told to just do it ourselves now with clever gradle sorcery.
m
I think it's easier for them. No more "state" on the server. You upload your files all at once.
It's also closer to what GitHub packages is doing I think? And also probably npm, etc...
a
Heh, certainly it's easier for "them" 😉
I don't know enough about npm packages to say
m
I'm happy that they are investing on the system. It's not perfect but if we have only one url and one way to publish, it's already something. Next we need stats and sigstore.
And also: no more jira ticket!
(but emails to central-support 😅 , not sure which one is best 😛 )
a
You'll get no argument from me about the maven-central/ossrh people getting their act together. That's fantastic. 😆 My issue is that KMP-publishing with all of its layers of sorcery doesn't fit will enough into their simplified paradigms. Maybe at some point the JetBrains people will get involved in this? I dunno.
At this point it seems light that might be needed
m
I blame cinterop here 😄
cross-compilation should be available in 2025
a
I mean... isn't the whole thing about KMP that c-interop is supposed to be a first-class citizen?
Otherwise we're back to JNI
nono 1
m
No idea, I have done very little cinterop but yea, feels like it should be easier
a
It feels like to me that KMP effectively stretches gradle as far as gradle can possibly go. Its almost like it "tortures" gradle into becoming a multiplatform build system, it's impressive that they pulled it off to be sure but still... As a result of this "torture," gradle becomes this extremely wonky thing and this wonkieness permeates everything that touches it.
This whole thing with the Central repo is yet another permutation of the wonkieness.
(...is wonkieness even a word? I'm getting tired)
m
Amper will fix all the things!
a
Huzzah!
On to the next tool!
m
Also congrats on David for creating this 100+ messages thread, I'll leave every one in peace now 😄
❤️ 2
a
Have a good afternoon (err... morning? err... evening?)
m
Evening here!
Have a good time of your day 🙂
👍 1
d
I still haven't taken the plunge yet with http4k and it's 190 modules... That's next week's problem and one I hope that you all will be there to help with 😉
kodee happy 1
🚀 1
a
Wow! Good luck!
Speaking of which, I should probably put together a code sample of ExoQuery with Http4k.
❤️ 2
I turns out that this 
ossrh-staging-api
was even more problematic then I thought. Whenever you try to do an upload to a repo-key 
username/ip/repo-id
combo whose IP you are not currently on e.g say:
Copy code
SIDUNF/96.227.221.53/io.exoquery--1a8de2d9-3a89-4d54-b478-a1d1491bd0b0
...and you are not on 
96.227.221.53
then the gradle publish won't even tell you the publish didn't go through. It will just fail silently! That means that if you do have a 
<http://ossrh>...service/local/staging/deployByRepositoryId
with a repo-id (from: 
profile/start
) you've meticulously woven through your build... the whole thing will fail silently if GitHub actions randomly decides to hand you a new IP address. This is what was happening in my 
macOS-latest
matrix build. GitHub assigned a new IP to the whole container which meant that the key was no longer valid and my uploads were missing artifacts. What was so awful about this whole thing is that there is zero indication that anything is wrong. In their "infinite wisdom", all three ChatGPT, Claude, and Perplexity kept telling me it was an issue of one Wagon connection clobbering another and some magic combination of 
--max-workers 1
and 
--no-parallel
would make my problem go away. I even introduced a 20 second timeout between my gradle upload tasks which of course did nothing. Of course at some point I just randomly started playing around with crap and found out that if I replaced 
setUrl
from 
<https://ossrh>.../service/local/staging/deployByRepositoryId/$repositoryId/
to 
<https://ossrh>.../service/local/staging/deploy/maven2/
and then manually deployed the 
SIDUNF/<IP>/io.exoquery--default-repository
entries I would suddenly see my expected 
macOS-latest
artifacts spread across multiple 
default-repository
entries (it certainly doesn't help that it's impossible to see what files are inside a repo key via the OSSRH rest API!!). Then I realized that it's this silent-wrong-IP failure issue that I happened to know about previously! All of this nonsense can easily set a developer back one or even multiple weeks. I will re-iterate, the feature-set that Central Publishing has is extremely primitive compared to what Nexus does. You can't even get the repo "description" fields into this 
publishing/deployments
thing! Let alone the fact that in s01/oss there were no nonsense IP-isolation restrictions, not only were there statistics, you could even modify a repo (even a closed one!) if validation failed, the most common reason for which was artifact duplication. Bottom line... it's very nice that after ~10 years they're finally working on real self-service Maven-Central infrastructure but I really miss s01/oss Nexus! I think the whole JVM OSS community is about to as well. (P.S. I also think the UI of publishing/deployments is also much worse than the old s01/oss one. In >99% of cases you don't want to see artifacts that have already been published, just the latest unpublished ones.)
😲 3
😬 1
P.S. You can forget about trying to get a list of what's in 
<https://central.sonatype.com/repository/maven-snapshots>
too btw. The UI for it is completely broken.
d
Messing around with the new publications for http4k. Scared to try it on a real project so have set up a test one for prototyping the gradle. We need to edit the POM file (which I think will be one type of fun), but we're also getting a problem with missing signatures... has anyone seen this or can comment on what we might be missing?
Screenshot 2025-07-01 at 22.16.08.png,Screenshot 2025-07-01 at 22.15.37.png
m
Did you configure your GPG keys?
d
ah - do I need new ones? we're using the originals from the old system. I can't see a place to upload them...
m
Old ones should work fine
But missing signatures happens to me when the signing plugin is not correctly configured or the GPG keys are not present in the environment
Something like so:
Copy code
signing {
  useInMemoryPgpKeys(signingKey, signingPassword)
}
d
ta. wil try that. I have been setting the environment properties instead
m
There are so many properties in Gradle...
d
yeah
m
I usually do
Copy code
signing {
  useInMemoryPgpKeys(System.getenv("GPG_KEY"), System.getenv("GPG_KEY_PASSWORD"))
}
same 1
I can never remember what is a project vs system property and where to define them other wise
d
I kind of thought that with the vannitech plugin we could drop the signing
m
Nope, Maven Central requires them
Oh, the block you mean?
Yea probably vanniktech will call that for you
d
we were using that
(the env: ORG_GRADLE_PROJECT_signingInMemoryKey)
m
Weird, that's supposed to work
d
this is my 15th hour trying to get this entire thing to work
😬 1
still no dice. But the signature files seem to be populated ok.... 🤔
m
So signatures are ok locally but not on the remote?
d
ah - actually I am missing the asc files, so it probably is the sig. Nice of it to not fail... 🙄
Copy code
http4k-core-6.15.1.0-sources.jar.asc.sha512
m
Yes, 
.asc
is the signatures
But you have the signature checksums but not the signatures? 😱
d
yep!
m
Wow
First time I'm seeing this
d
I was missing this line...
Copy code
signing {
                val signingKey: String? by project
                val signingPassword: String? by project
                useInMemoryPgpKeys(signingKey, signingPassword)
                sign(publishing.publications) <---- 
            }
🎉 2
it validates ok now at least...
onto the pom manipulation!
m
Good catch!
d
thanks for your help... think I'm almost there so am going to go and lie down in a very overheated room for a few hours. I was at it until 1am yesterday so I'm going to quit whilst I'm ahead! 😂
😂 2
o
@dave I wonder what was the main problem. Normally switching to vanniktech is quite straightforward. I have never tried it's built in signing though (iirc)
152 Views
Open in Slack
PreviousNext
Powered by