https://kotlinlang.org logo
Join Slack
Powered by
Maven Central's <new publishing limits> make publi...
# multiplatform
r
Maven Central's new publishing limits make publishing KMP projects extremely difficult: I have 3 multiplatform oss projects, each with 1 release this month, and am already at 100MB/15MB and 5k/300 files. They are libraries that target all targets, so higher than most, but the limits are so low I would expect pretty much any KMP library to hit them. Someone at JB may want to reach out to sonatype about this, or even consider a kotlin focused artifact repo (as a last resort, hopefully)
😯 2
c
Woah, those limits are so much lower than I would have expected. I released a project a week ago with ~30 Gradle modules, and that one release has already put me significantly over the limit over the month. While I acknowledge that a 30-module project is certainly not typical for OSS libraries, it's also far from extreme, especially if you consider that many folks who maintain an OSS library often maintain several different projects. This really is a major problem for KMP libraries. Hoping the Kotlin team can help Sonatype set more realistic limits here.
h
These limits are very low for a KMP library, and we should send our feedback to MavenCentral. If you are using GitHub, you could release the binaries to GitHub packages, but it is not without pain (required login and availability).
d
☹️
r
I've just made a single release of Kilua ... 🤣😭
😅 2
h
Looks like the current limits are already higher than the initial ones 👀
r
I understand the problem, though. It does seem ridiculous I need to publish 10K files for a single release of a framework, which is not even targeting all KMP targets, just JS, WasmJS and JVM.
➕ 2
The release size is just 15MB (out of 80MB limit). If it could be published and hosted as a single zip file, it would probably save a lot of infrastructure resources.
Perhaps it is time to start thinking about it.
j
Relevant work item from the Kotlin roadmap: https://youtrack.jetbrains.com/issue/KT-68323
Seems like we should voice this concern there as well
z
Hi folks, just to confirm, we've seen this and will be looking into it.
👍 6
👍🏾 1
c
Single release of Spine
j
FYI: https://central.sonatype.org/publish/maven-central-publishing-limits/#exemptions-for-community-open-source-projects
Some legitimate community open source projects may have unusual publishing patterns. Exemptions are available for qualifying community open source projects and are reviewed on a case-by-case basis
c
Yeah, I saw. I'll wait until Márton gives us the official JB answer since it's probably all Multiplatform projects and not "unusual publishing patterns". But also, OpenSavvy has 30 repositories, 7 releases per month is nothing if we weren't multiplatform.
(all our releases are already published to our own GitLab maven registry, but it's a big barrier to entry to ask users to configure it)
z
On a personal note, I'd just go ahead and start requesting exemptions for your open source projects via the support email, so they see the demand and hopefully grant the exemption https://central.sonatype.org/publish/maven-central-publishing-limits/#exemptions-for-community-open-source-projects
👍 3
✔️ 2
👍🏾 1
c
Looking at the actual repo content, the ratio of "actual file" to "hashes and signatures" is 1/10 😕 https://repo1.maven.org/maven2/dev/opensavvy/spine/client/0.11.0/
b
Maybe it could be a good opportunity for libraries to start publishing elsewhere. While having a central place for all libraries is handy, it’s also not a great idea in general.
c
Nowadays, that's not even difficult for the library authors. But the discovery/tooling on the user side is not ready for it at all.
b
discovery/tooling on the user side is not ready for it at all.
If a library currently publishes to Maven Central and switches to another repository, users won't be notified of new versions. That's one issue. Are there others?
c
If you add a dependency and you have not configured the repository, the error message isn't amazing.
Also, with custom repositories, you have no guarantee of version immutability, which is a very important protection against supply-chain attacks.
b
Good points!
c
I wonder if it would be possible to have a mini-central that just stores the hashes of first deployment but proxies to an external repository so the bulk of the storage is offsite
✅ 2
I wish I had the free time to prototype that, I've got a few ideas 😅
doit 2
j
If klibs.io would have its own repository users would only have to add it once for many KMP libs 💭
c
klibs.io doesn't index non-GitHub and non-Central projects, why would we trust it as the single source of truth?
j
Not as single source, but an extra one. A KMP-focused central repo.
c
Right. Well even with the new rules, Central is still less restrictive than klibs 😅 Even if they fixed all that and went that way, I'm not sure I would trust them to make good decisions in the future
😁 1
o
A single TestBalloon release set in May for 8 Kotlin versions (the numbers shown for April and June are fantasy):
🤣 1
a
Do checksum and 
.asc
signature files also count towards the file limits? If so, then Gradle should be fixed because at the moment it generates unnecessary checksum files https://github.com/gradle/gradle/issues/20232
c
I see nothing saying they don't
a
I investigated an alternative a while ago: attach libraries to GitHub Releases. https://github.com/adamko-dev/argh/ The UX is much better than using GitHub Repositories. Consumers just need to add the Gradle/Maven plugin, no need for separate repos per library, or tokens. I haven't had much time to work on it, so it's not very polished. Feedback and contributions welcome! I think Argh is good for prototyping, or snapshot releases, and potentially could be paired with immutable releases.
h
Unfortunately, GitHub Releases only supports 1000 files per release, and a library with many targets and some modules reaches this limit very fast, even if you disable the checksum files (because GitHub release assets has built-in checksum support).
r
Argh could handle this by putting all platforms in a single archive (which ofc would hurt downloading). I had similar thoughts about using GitHub releases, it's nice to see there's already something in that direction. Maybe this will push GitHub to make Packages actually usable for the JVM/Maven/Gradle ecosystem
c
b
Hey that’s me. I see this thread and the other at https://kotlinlang.slack.com/archives/C8C4JTXR7/p1781796910192089?thread_ts=1781680033.508269&cid=C8C4JTXR7 what’s a good place to consolidate the conversation? I want to understand better what’s going on with Kotlin and why it seems anecdotally to be over represented in these >10 percentile numbers
r
The issue is quite simple. Even small KMP projects generate a lot of files (and I mean a lot - see examples above).
✅ 2
j
b
90 Views
Open in Slack
PreviousNext
Powered by