Hello! I was wondering if Gradle has a way to prog...

# gradle

[axeon]

Hello!
I was wondering if Gradle has a way to programmatically parse a build file. So far, I’ve only found that it can be done using GradleConnector, but it feels pretty slow, likely because it still launches a Gradle daemon to process/build the project in the background. What I need is the project's dependencies and source sets. If not, I will likely have to parse it using regex but that would be a pain to implement.

[Vampire]

And pretty unreliable unless you control the build script.

There is a multitude of ways to set dependencies.
If you want the dependencies from an arbitrary Gradle project, you have to use the tooling API like an IDE does.
No parsing can ever be correct, as the dependencies could also come from plugins, from a version catalog, calculated, conditional, .....

[axeon]

I'm aware of the amount of work involved if I were to handle the parsing myself. For now, I'll look at how they implemented the parser for some inspiration, though I’m not expecting it to be very helpful.

[Vampire]

There is no own parser, build scripts are Groovy scripts or Kotlin scripts. They are executed and then the resulting model has the necessary information.

[axeon]

Oh right, then there's no other way around I suppose.

[axeon]

The tooling API takes around 16 seconds to connect and resolve the model on a cold start, which is a significant bottleneck in my project in terms of both execution speed and memory usage.

[axeon]

One thing I can think of is to compile the build script myself, at least the Kotlin DSL part. Not sure how Kotlin scripts are handled but I'd probably have to add the Gradle Kotlin DSL library to the classpath and feed it to the embedded compiler

[hfhbd]

It’s not only about compiling/parsing, dependencies can not be added by the user but also by plugins.
If you want to frequently check the dependencies, you could write the dependencies you need regularly using Gradle to a file and parse the file.

[axeon]

Got it. I'll stick to the tooling api. Is there any known way to speed things up?

[hfhbd]

Use configuration cache

[Vampire]

I don't think that will be relevant for getting the dependencies via tooling API.
The configuration cache only kicks in if you execute some task and the according task graph with its properties can then be taken from configuration cache.

[hfhbd]

Yeah, but if you use a task that write the dependencies you want to a file, the config cache should fasten rerunning this task

[axeon]

I don't have control over the build file, so I likely can't declare a task

[Vampire]

You can, using an init script.
But I still don't think it will help much.
And even if, then it would also only work if the task in question is CC-compatible.

[axeon]

Unless that's within the tooling API's capabilities, I don't think I can. I'm building a language server that shouldn't depend on user input

[Vampire]

It is

[Vampire]

But I still think you shouldn't 🙂

[axeon]

I could make use of it if I knew the format in which Gradle stores the configuration cache binary, though it's probably a custom format

[Vampire]

No you cannot and that will also not help much and be highly fragile.

[axeon]

Hmm, how about using the cli? Seems significantly faster to me. And I can always fall back to the tooling API in case the cli is absent.

gradle dependencies --configuration implementation -q

[axeon]

Although I'm not sure what I'm going to do about source sets

[hfhbd]

I think, you do know the answer, the tooling api :D

[axeon]

Yeah, it seems there's nothing I can do about it

[axeon]

the Kotlin ecosystem/env is incredibly complex, but I guess it is expected given its interop with Java

[axeon]

Thanks for all the help!

[Vampire]

Using the CLI is not faster, the CLI is doing the same as the tooling API.
It starts a daemon and does what you told it to.
If you observe the CLI is faster, then maybe because either an already running daemon could be reused and when you used the tooling API it couldn't, or some things were up-to-date that were not up-to-date before.

[Vampire]

But also, you should not run the dependencies task using the tooling API and parse the result, but ask via the tooling API "give me the dependencies" just like IDEs are doing it.

[axeon]

I'm using the IdeaProject model to achieve that

[axeon]

> Using the CLI is not faster, the CLI is doing the same as the tooling API.
Perhaps it's because of the configuration cache? I do stop all the daemons before running tests

[Vampire]

If you enabled CC in the project in question and it could be reused, yes