https://kotlinlang.org logo
Join Slack
Powered by
MavenCentral is implementing a publishing limit on...
# library-development
c
MavenCentral is implementing a publishing limit on August 11: https://central.sonatype.org/publish/maven-central-publishing-limits/ You can check your current usage here: https://central.sonatype.com/publishing/usage The limits are very low. A single release of https://spine.opensavvy.dev (which is not even a big project, but it's Multiplatform) exceeds the monthly quota.
z
r
I wonder if it could be possible to workaround the problem by changing the way KMP artifacts are published and consumed on the Gradle plugins level. Libraries could be published as single zip/jar archives to Maven Central (should be fairly easy to do this with a plugin like nmcp, which just zips and uploads the local publication). Then, applying some Gradle plugin for a consumer project would download the archive and unpack it to some local repository. Adding a plugin on a consumer side would be the only change required. And the Central infrastructure, immutability, versioning, notifications would work without changes.
w
Seems silly. I think sonatype just needs to rethink the limits. I think they will get some significant pushback
b
Hi everyone. @Zac Sweers pointed me here since I reached out about getting more feedback on the publishing limits as it relates to Kotlin.
👋 8
👋🏾 1
There’s a giant thread in #C3PQML5NU too.
c
I believe the TL;DR of the difference is Kotlin Multiplatform specifically. Whereas a typical Java library releases one JAR per module, Kotlin Multiplatform libraries generate one JAR (or one KLIB) for each platform they support, plus some metadata. Since there are ~15 popular platforms, the limits are essentially ×10 smaller for us than they are for the typical Java library. I think that's the main reason why so many more of us are above the threshold, compared to the average Java maintainer.
✅ 2
z
@mbonnin and @Josh Friend have some giant examples from apollo and sqldelight too, where I believe they can't even do one release without exceeding limits
(just looping in relevant peeps from other threads blob grin)
s
Even plain Kotlin/JVM with platform-native helpers has 5x the usage (win x64, win arm64, mac arm64, linux x64, linux arm64)
➕ 1
c
(without even going into such massive projects, OpenSavvy projects are average-size and exceed the monthly limits in a single release)
m
Yea, this is our current state
It's not huge but it is a loooot of files
b
Which thread do we want to use?
or maybe just I should start a new one?
c
Maybe starting a new one is simpler, yeah. I think #C8C4JTXR7 is the best place. We'll find the other ones and link to yours.
b
k
s
I did one small release of my small library with a bugfix and I am already ~50% there on the files count (Kotlin/JVM + native helpers + a couple optional artifactIds)
c
I'll copy my TL;DR about KMP in the new thread
b
h
BTW there is also no package private visibility in Kotlin, so it is common to create multiple modules, resulting into more published files than a normal Java library.
➕ 2
c
Just looking at some numbers from my last release, I published ~30 Gradle modules from a monorepo, and each module produced ~100 files, most of them small (file hashes, Gradle metadata, etc.). a single release pushed me over 3000 total files, which represented 27MB of space on disk. Kotlin produces a separate Maven Artifact for each Target, and so one KMP Gradle module could produce anywhere from 3-20+ individual Maven artifacts, depending on what Targets are supported. My project, for example, includes the following targets: • JVM • Android (Debug) • Android (Release) • iOS ARM simulator • iOS x86 simulator • iOS x86 • JS • WASM JS • + 1 common "metadata" artifact This layout is pretty typical for KMP projects, but you can easily end up publishing more artifacts if you're supporting specific Native targets, for example. The math ends up being something like 
(Gradle Modules) * (KMP Targets) * (10-15 files)
for each library. The size on disk isn't extreme, but the publications end up with a ton of files due to the metadata generated for each target.
👍 1
Just my 2¢ here, but it seems like the main metric really should just be size on disk. The number of files is pretty arbitrary when most of them are small, and limiting the number of releases per month could pose a security risk if a bug is found but we cannot publish a fix (or need to get explicit approval to push the fix). The size on disk, though, does map pretty directly to the actual scale of the project. Large companies will almost certainly have vastly more code in their SDKs (often including large native binaries) than a typical OSS library, whether it's in one Gradle module or spread across many. But the sum total of the size of a release plus the release frequency is what would be contributing to such inflated numbers for those projects.
💯 4
z
@Casey Brooks get in the other thread
b
@Casey Brooks yes-ish, until people start sharding things. But this was all just meant to be a reasonable upper limit that creates an inspection point to drive at least a conversation. Yes the counts are off for KMP but set that aside. My intent was that above some limits that don’t apply to most (90%) we have a point to look at is the project open source or is it open washed. If it’s open source, no problem, move the limits.
👍 2
And the hard limits would take an action, but not nessessarily “you can never publish again this month”
20 Views
Open in Slack
PreviousNext
Powered by