This message was deleted.

There's nothing lightweight you can embed. Your best shot might be to use the Tooling API to instrument Gradle

Do you mean running the actual Gradle as a separate process and get information from it via the tooling API? If so then maybe I'll have to stick to this maven resolver. I'm a bit frustrated with it given the amount of boilerplate setup, and inexistent doc, hence why I was hoping for Gradle to save me on this 😄 But I guess it would overcomplicate things to spawn an extra process for it

You can use the tooling API in "embedded" mode that will not fork another process. But this might "complicate" your current running process 😉

Thank you very much for the details. I had never looked into the Tooling API. Am I right that it is rather meant to drive an existing Gradle build (with build scripts and all)? My use case can be reduced to the really simple case of having one set of artifact coordinates (groupId, artifactId, version), and downloading all dependencies and get a handle on the downloaded jar files. It seems that using the Tooling API would mean generating a build script and then running Gradle on it, which seems a bit overkill, right?

Yes that's how it would work

Ok thank you!

But you might think it is more complex than it is. You do not need to "run gradle in a separate process and then connect to it using the tooling api". You would generate your small build script, and then you tell the tooling api to run that build. The tooling api will then care about starting a Gradle daemon that runs the build for you, so it should be quite easy. You could then do the lazy way and write your generated build script so that it prints the paths and you parse the output, or you can do it the better way, asking the tooling api to give you the dependeny files. It is exactly what IDE integrations do.

as an alternative, it doesn't support GMM and other features, but https://get-coursier.io/ does provide a simple API to resolve Maven artifacts

@Vampire even if it doesn't make the code I write myself complicated, it does feel like a lot will be going on for just downloading a few jars, and the memory and processing overhead compared to the current alternative may be significant. I do value the benefit of having Gradle dependency conflict resolution, but I'm not sure this would be worth it. I'll keep the option in mind, though. We might eventually move from Kotlin Scripting to an actual generated Kotlin+Gradle project in the far future, in which case this approach with Gradle Tooling API would be perfect.

I guess the overhead will not be that significant, but you would need to measure to know 🙂

For the sake of the exercise, if you repeatedly need to download artifacts, you could keep the daemon alive. If it is only needed for that it could be started with a tiny heap.

And you would have the benefit of the Gradle Module Metadata being used / ability to use feature variants and so on, all the nice things you can use when using a Gradle build. :-)

The use case at hand is a Kotlin Script DSL that we process rather unconventionally. So we embed the Kotlin compiler, and need to download dependencies by hand. This happens on the fly in a short-lived docker container (itself possibly spawned in a short-lived VM), so we wouldn't benefit from a longer-lived daemon, nor Gradle caches. Currently the annoying part is that dependencies added to the script via

@file:DependsOn

are processed independently, via a Maven resolver. The only thing I'm trying to resolve by hand here is our own DSL runtime (apart from the user dependencies), which has transitive dependencies, but is currently passed as a fat jar 🤮 with all the problems that come with it. Eventually I'll need a way to resolve dependency conflicts between the user's dependencies and our own runtime+transitive dependencies, but that's not for today I guess

Kotlin scripting itself uses Aether, which I assume is where you started investigating https://github.com/JetBrains/kotlin/blob/master/libraries/scripting/dependencies-m[…]pt/experimental/dependencies/maven/MavenDependenciesResolver.kt

Exactly. Actually initially the

.main.kts

implementation (which is not the same as our own

.space.kts

in Space Automation) used an Ivy-based resolver, and we still use this implementation at the moment in Automation. I'm switching right now to this

MavenDependenciesResolver

in our own implementation to get rid of Ivy, but this only concerns user dependencies provided by

@file:DependsOn

. Our built-in DSL dependency is provided separately and still resolved manually using Ivy. This is the thing I'm also replacing now, using Aether too, but independently of this

MavenDependenciesResolver

.