https://kotlinlang.org logo
Join Slack
Powered by
is there a remote chance to use <Gradle Version Ca...
# scripting
p
is there a remote chance to use Gradle Version Catalog with 
@file:DependsOn("...")
? 🙈 scripting would have to know where to look for the TOML file, and it's non-trivial to infer. It could traverse starting from the script's location, up the file tree, until it finds 
gradle/libs.versions.toml
I'm shamelessly ignoring the fact that Kotlin Scripting and Gradle isn't integrated in any way, but I thought I'll ask anyway since the Catalog may be usable as a stand-alone tool?
ah, and IDE support would have to be present here
m
Probably not the answer you're looking for but I think scripting shouldn't aim to support version catalogs if it wants to remain simple.
Generally, I would like 
*.main.kts
to know nothing about Gradle
p
Gradle as a build system - yes, but the version catalog serves having no duplicated version which is appealing in a project where one uses both Gradle and Kotlin scripts
m
If you have Gradle in your project, what do you gain by using scripts compared to a custom 
JavaExec
task where you can control everything?
👍 1
p
calling the script directly, like with github-workflows-kt - so simplicity, as you write 🙂
m
Make a shell script that calls 
./gradlew runScript
?
I understand the appeal of adding more features to 
*.main.kts
but this is a dangerous slope IMO
p
Make a shell script that calls 
./gradlew runScript
?
then github-workflows-kt would have to be aware of using this way of running the script
yeah, I understand and agree that the main goal of scripting is simplicity, I just started wondering... 🙂
m
👍 curious to hear what others think.
p
but e.g. support for compiler plugins should probably be added - it's an important part of Kotlin, and simplicity doesn't justify the current feature imparity
m
That doesn't involve Gradle, count me in 😄
👍 1
Some time ago, I wrote an issue about adding Gradle metadata support to the 
*.main.kts
resolver but I think I changed my mind
Library producers can be maven compatible if they want to (they should)
👍 1
p
adding to the version catalog thing: nothing stops me/anyone from writing a piece of validation that would check that the version defined in the version catalog matches the one used in the script. However, I'm not super-enthusiastic to do it, it does feel itchy
m
ORG2IPeMldoVuz9603AOq5JyN_52_sds0qyevl5MlvU.webp
ORG2IPeMldoVuz9603AOq5JyN_52_sds0qyevl5MlvU.webp
v
I don't think 
.main.kts
should support version catalogs ootb, especially not with a hard-coded Gradle-specific location. Once compiler plugins are possible, maybe you can implement that as compiler plugin. đŸ€·â€â™‚ïž Gradle module metadata support on the other hand would be great. For example when some library has mutliple feature variants, or different variants depending on Java version, or for example a multi-platform Kotlin library.
a
I think it'd be reasonable if main.kts had some way of declaring a custom dependency resolver service. By default it'd just be the simple Maven resolution, but you could implement your own custom resolution if required.
👀 1
m
Is there anything else than the ivy aether resolver used by 
*.main.kts
(that was quite dated from what I remember when I looked at this a long time ago) and the Gradle implementation (that is very tightly ties to the Gradle binary and boderline impossible to use outside of Gradle)
Not saying this isn't a good idea, it'd be great but in practice, it's probably not going to be super used....
Unless of course this creates an opportunity and more folks start implementing new resolvers 🙌
v
*.main.kts
does not use Ivy
👍 1
It uses Aether, the resolution engine that is also part of Maven
👍 1
m
Ah, yes! I remember now. I struggled to find the code for that
I think I ended up on sourceforge at some point?
v
Ah, yeah Aether was dead and with 1.7.20 they switched to 
org.apache.maven.resolver
Which still has aether in the package name, so probably a fork
m
Ah!
Much better.
There's even a GitHub repo 👀 https://github.com/apache/maven-resolver/
➕ 1
p
Is there an analogous resolver lib for Gradle?
m
Nope, I asked some time ago and the answer was that it was probably never going to be done given how tightly integrated it is with the rest of the system
😐 1
v
Well, you can use the whole Gradle distribution. 😄
Or if you are dedicated enough, you could try to refactor out the resolution engine so that it is usable stand-alone and send a PR upstream, hoping they are open for it. đŸ€·â€â™‚ïž
m
That was more or less the plan but I gave up really early 😄
😭 1
5 Views
Open in Slack
PreviousNext
Powered by