https://kotlinlang.org logo
Join Slack
Powered by
Given recent panic with jcenter shutdown, I've sta...
# announcements
b
Given recent panic with jcenter shutdown, I've started thinking that it'd be nice if jetbrains could come to some sort of partnership with google and endorse google package registry as official kotlin registry. Given that main use case for kotlin is still android development i think it would make a lot of sesnse for both companies. Furthermore, I'm not sure that tying kotlin to "legacy" technology such as maven is the most future-proof way to go. I'd like to hear what JB and the community thinks about the idea.
➖ 1
👎 1
r
Calling Maven a "legacy" technology is definitely a bold statement 🙂
➕ 13
😂 1
v
As is saying Android is the main use-case
➕ 1
☝️ 7
b
I know, it's just my personal oppinion
As for Android being main use case, it's just statistics, nothing personal
➖ 1
👎 1
v
Even if Maven as tool is legacy, which I would agree when there is Gradle ftw, Maven repositories are imho not. Besides that, why do you think Kotlin is in any way tied to Maven or Maven repositories? You can use any repository supported by Gradle, including arbitrary URLs or flat files.
b
Server-side is growing, but it's not quite there yet.
As for maven stuff, i mean that maveCentral has indirect link to "maven-first" mentality. I know that grade supports maven repos, but that's basically just a smart move to easier integrate into jvm ecosystem (since maven established first). I think someone "neutral" or gradle focused would enable more future optimisations
n
funny i just add a conversation about maven and gradle at fosdem
v
The problem is, that then everyone has to release to multiple repositories to support both and if someone is not willing, he cuts off the other users and so on. What's wrong with using the existing repository for free and thus serving all users at once? Now with the Gradle metadata you also have the "additional optimizations" possible that suffered from the limits of poms.
b
My main concern is basically that there's no "kotlinCentral" repo
v
Well, why operate an own if there are well-known free alternatives? :-) Storage and bandwidth are not for free. And also that would be a but elitaric. :-D
e
Maven Central is something of a special case (the majority of the ecosystem is already there). beyond that, I really don't believe in having any officially blessed registries
we don't want to be like Docker where the single public registry suddenly decides to implement download throttling because it's expensive
➕ 4
it should be (and it is) easy to use a diverse set of repositories and migrate between them
b
Thanks for your opinions, guys! Realy interesting to hear community oppinion on this. Might be just me that's missing "kotlinCentral" then 😀
c
You might want to read this (a JB employee answered a few questions in the thread): https://kotlinlang.slack.com/archives/C0BJ0GTE2/p1612372634063700?thread_ts=1612372634.063700&cid=C0BJ0GTE2
g
I’m against kotlinCentral at least now, maven is good for all existing use cases, it’s strict and reliable jcenter alwasys had pretty bad service Maybe JB decide to invest into this, but honestly it looks that work together with maven central is better strategy for whole ecosystem
c
Quite frankly, I wouldn’t want Google to be part of a new “central” repository. They have an incredible track record of not keeping things around for very long (https://killedbygoogle.com/)
➕ 1
e
Google isn't particularly better or worse at this than the average tech company, it's just got a lot of reach
☝️ 1
b
Hi all, Brian Fox from Sonatype / Maven Central here. I was asked to hop over here given the conversations around repo might be easier this way. I’m happy to have a conversation about if Central is the right place for your use case. Also, if it’s not, I have a lot of battle scars that can help inform how you might approach an independent kotlinCentral if you’re so inclined.
🙏 7
👍 10
e
what if the standard slowly moves towards hosting not only the source, but the built packages and binaries themselves on GitHub?
v
That will probably not happen as long as anonymous access does not work.
👍 2
m
j
Wouldn't any kind of kotlin central require ensuring no duplicates or artifacts stepping on each other between maven central and kotlin central?
k
People tend to severely underestimate the complexities of running a "free" repo
☝️ 1
j
👋 I'm a security software engineer working at Gradle, I'm also one of the maintainers of the Gradle Plugin Portal.
b
@jlleitschuh you follow me everywhere eh? 😉
j
Hey, I'm pretty confident I was here first 😆
☝️ 2
b
I’m not familiar with the kotlin coordinate system, but if it’s the same as Maven, yes that would be a concern. But if things are in different repos and have different coords, it shouldn’t matter.
Touche
😄 2
@Kirill Grouchnikov yes, you have no idea. It’s also one of those things that can be very hard to pull off successfully in a truly federated way without it devolving into the tragedy of the commons
j
I think that Kotlin just leverages the maven standards. I'm not 100% certain about that. But Gradle is used to build most Kotlin projects. And unless Jetbrains did something special inside their Kotlin plugins, it should operate in a pretty equivalent manner
👍 1
b
I see. Well, as I wrote in my blog today, that’s actually a benefit of dns based coordinates. It’s a separate naming authority, if different repos follow it, then you shouldn’t have a conflict
j
I don't know how LLVM or JS published components work
Agreed, assuming that all the packaging hosts all check DNS in a consistent way
I noticed some of your documentation says that MC doesn't require you to demonstrate ownership of a DNS record to publish there
b
If you choose eg com.github.xxx and can prove you can commit to that repo
j
Right, so for everything else you require proving you own the TLD? If it's not on Github?
b
there could be a few others like that, but we require validation that is sensible for your stuff.
We’re trying to be a little flexible for historic things, like we did for deepsearch but still maintaining the integrity of the validation.
We required a new dns for go forward, and validated ownership on jcenter for the old stuff too
j
Is this stuff enforces with policy or code? And if it's code, is that validation logic OSS. Because we do a lot of it by hand, and if we could automate more of it on our end, that would make our lives easier
b
It’s both. For the normal path it’s all automated. For things that are migrated, we look at it manually because it is outside the norm a bit
j
Makes sense!
b
But to the extent that other repos might want to leverage that same stuff, yes we should oss it. I’m not sure how bespoke it is, but will find out. I’m also thinking about opening up the validation of other bits of the releases themselves too so we can have others help, eg find something better than pgp signing
j
We currently manually check every submission. I know that Jitpack has some automated system for checking DNS. Would be good if we could all converge on a similar standard bit of code for doing all that potentially. It would decrease the risk that we step on each other. I've also thought about something like an equivalent of ICANN for the JVM ecosystem to make sure that two organizations aren't being abused in a timing attack to register JVM coordinates at the same time.
b
Well, assuming everyone leans on dns and uses shared mechanisms to do so, you don’t really have to worry about it. Only one org can own the dns.
j
I was more concerned about timing attacks when JCenter was still in play. I was going to raise a stink about it eventually. I just never got around to it. Now the point is more moot
b
RIght.
But that’s why I was asserting dns while imperfect, is still a pretty solid approach.
it tends to eliminate the whole leftpad thing which was caused by a fight over a separate set of coordinates. That simply can’t happen in this case, or at least if it does, there is a well paved path for disputing cyberjacked names
j
"How could I break the JVM ecosystem supply chain" has been a mental exersize for the past two years for me. Playing in the back of my head.
b
j
I had not read that bit of coverage yet. I will now
@Brian Fox did you ever read about the very first security vulnerability I ever found/disclosed? It was in the Gradle Plugin Portal, from before I joined Gradle. https://link.medium.com/bpPxUUZfMdb
b
oh shit, almost the same thing. No I hadn’t seen that before
n
Some of the Gradle plugins have some dependencies that haven't moved to Maven Central. Dokka ( https://kotlin.github.io/dokka/1.4.20.2/ ) is one of the plugins that isn't usable given the current situation, which prevents many Kotlin libraries from migrating to Maven Central (no way to generate JavaDocs).
k
If you're referring to the Markdown dependency, see https://github.com/JetBrains/markdown/issues/64
👍 1
n
If Sonatype are serious about providing Kotlin support then they need to allow HTML to be used instead of JavaDoc for supplying documentation when publishing a library. This is essential for Kotlin Multiplatform projects ( https://kotlinlang.org/docs/multiplatform.html ) where JavaDoc can't be used for providing documentation (only works on the Kotlin JVM platform, not on the Native, JS, and Android platforms). It is recommended that @Brian Fox experiment with a existing Kotlin Multiplatform project by generating HTML documentation (via Dokka - https://kotlinlang.org/docs/kotlin-doc.html ), and see what additional support needs to be added to the OSSRH, and Maven Central repositories to support Kotlin Multiplatform libraries.
v
Why can't you provide JavaDoc for usage with JVM and html additionally? You can store any amount of artifacts in a release.
❓ 1
n
The project I want to publish (to OSSRH) is a Kotlin Multiplatform library ( https://gitlab.com/napperley/kmqtt-client ), which means JavaDoc can't be generated by the Dokka Gradle plugin. Dokka's Kotlin Mulitplatform support is only covered by the Dokka HTML plugin, NOT the Dokka JavaDoc plugin (only covers Kotlin JVM).
j
if you jar up the dokka output directory and add a javadoc classifier to it, maven central is happy enough to have a "javadoc" jar even if its not properly javadoc (its also happy with an empty javadoc jar file for that matter) fwiw
n
How is the Dokka output directory turned into a JAR with the JavaDoc classifier in it?
v
Just do it?
The "classifier" is just a part of the name
And the Jar task of Gradle has an attribute for the classifier
b
I’m gonna pretend not to see that ;-)
Seriously though, revisiting that javadoc rule is on my list. Seems like since it’s so frequently worked around, that it’s not really effective anymore.
v
No, please don't loosen the rule. 😞 It is ultimately helpful that most libs on MC actually have source and javadoc present.
(speaking for the Java ecosystem of course 😄)
n
The key issue here is that the JavaDoc rule lacks flexibility to cater for additional documentation types (eg KDoc in HTML form).
👍 1
☝️ 1
b
Yes. We need to do one or the other.
Because a bunch of fake javadoc jars doesn’t help anyone and just makes work
👍 2
n
Would be good to hear from the Kotlin team (@Alexey Belkov [JB]) on how KDoc is recognised in IntelliJ (eg what does the IDE look for when picking up KDoc based documentation - what are the requirements).
11 Views
Open in Slack
PreviousNext
Powered by