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
💙 3
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 😔
😲 1
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