https://kotlinlang.org logo
Join Slack
Powered by
Quick feedback on my first use of the Kotlin toolc...
# kotlin-toolchain
j
Quick feedback on my first use of the Kotlin toolchain... I’d really like to add a local maven repo that isn’t the default (
~/.m2/repository
). I’m using a bit of the Kotlin Toolchain inside of a larger, gnarlier Gradle project, and I’d like to publish libraries from one to the other, without dumping stuff into the host computer’s shared Maven Local repo. Duplication between modules hurts. Each of my modules does this and it’s boilerplatey and risks getting out of sync.
Copy code
settings:
  kotlin:
    version: 2.4.0
  jvm:
    jdk:
      version: 25
The docs are excellent! I particularly like the reference section. Some small snags I ran into: • the 
mavenLocal
repo is undocumented. • the docs say 
wasmWasi/app
but the latest code wants 
wasm-wasi/app
I think this tool is absolutely excellent. I’m looking forward to adopting more of it.
💜 8
j
Thanks a ton Jesse for the feedback! Regarding duplication, have you looked into templates? They are meant exactly for this purpose.
j
That is what I'll do next
I didn't know templates existed to be honest
j
We'll check this maven local stuff. Indeed it's a bit hidden at the moment
u
We also might consider duplicates detection and suggesting extracting common configuration pieces to templates. Thanks a lot for highlighting it!
💯 1
j
the 
mavenLocal
repo is undocumented
It turns out @alexey.barsov added documentation for this last week. It should already be in the "dev" version of the docs (there is a selector at the top).
💯 1
I’d really like to add a local maven repo that isn’t the default (
~/.m2/repository
). I’m using a bit of the Kotlin Toolchain inside of a larger, gnarlier Gradle project, and I’d like to publish libraries from one to the other, without dumping stuff into the host computer’s shared Maven Local repo.
About this, did this need only come up because you're trying to make Gradle and the Kotlin Toolchain work together, or did you have similar needs in pure Gradle projects too?
j
I've had similar needs in all-gradle projects. It's also very handy as an alternative to includeBuild()...
Suppose I'm working on a feature in OkHttp that requires a new API in Okio. I might add code to Okio, publish to a local repo, confirm it works in OkHttp, and then send 2 PRs
This is possible with Maven local, but clumsy because if I'm not careful I'll leave a version there that impacts other projects
j
I see, thanks for sharing. So your main concern is isolation here, right? If I understand correctly, you want to use a local repository as a way of sharing artifacts between projects, but you want full control on the subset of projects that access these artifacts, so you prefer using different local repositories for different sets of projects.
I'm mostly playing the devil's advocate here, so please don't take this as pushback for this proposed feature, but how exactly do you expect other projects to be impacted (if you stuck to a single standard local repo)? If you use a special version number like 
1.2.3-my-special-fix-SNAPSHOT
, isn't this enough?
j
The situation I'm currently using it for is to share code within a single repo. https://github.com/wasmcomputercompany/brevity/tree/main/brevity-integration-tests#maven-local
If I had two independent clones of that project in two different directories, I couldn't run the tests concurrently without them colliding
j
You could, if the version you used somehow contained the identity of the clone (like a hash of the path), but I get the point, it's cleaner if this lives in the build dir and stays as local as possible. Thanks for sharing! We actually have the very same case for our own Kotlin Toolchain project, and for now we just use the standard Maven local, but it might be better to isolate this.
15 Views
Open in Slack
PreviousNext
Powered by