How to programmatically via API get project's classpath from gradle (not in a plugin)

Help/Discuss
1

Hello, would you be able to provide me some guidance / ideally example project code how one can programmatically via Gradle’s “API” (?) get a project’s classpath? This is NOT from within a Gradle plugin, but in “standalone” - so the ideal reply would be an example project, with the necessary Gradle dependencies, with something like a main() which as input takes a path to a directory with a regular Gradle project in it (as in with a build.gradle et al), and which as output prints the local paths of the project’s output directory where the *.class are as well as to the JARs of the compile.dependencies - on the fly resolved and downloaded its dependencies from that project’s repositories, etc. All of this “embeddable”, so pure Java - without some exec of some gradlew kind of approach - you know what I mean.

The goal of this would be that I’d like my https://github.com/vorburger/hotea library to have native Gradle support. (So you would point hotea at a directory, and it would return a ClassLoader - with all dependencies loaded fetched.)

If Gradle cannot be used “embedded” like this, or if this is a Stupid Idea for some reason, please enlighten me, and perhaps propose an alternative… I could probably run some gradle task and parse it’s CLI output, but that seems a bit… stupid.

Thank you!

2

Hi Michael,

nice to see you here too :wink: What you are looking for is the Gradle Tooling API. Give it a shot :slight_smile:

Cheers,
Stefan

3

Hi Stefan,

and you! Tx for reply - I obviously had no idea about the Gradle Tooling API - looks great.

My current Gradle known-how is end-user only, and what I’m missing is how to obtain the local paths of the project’s output directory where the *.class are as well as to the JARs of the compile.dependencies from a ProjectConnection… presumably there is some “Model” for getModel() for this - but which/how?

Thank you!

4

It depends on what you want to mimick. There is the EclipseProject and the IdeaProject model for instance. The models are very use case specific, since we don’t want to expose too many Gradle internals (as that would hamper future evolution).

If you dare to take the dive, you can actually inject custom model builders into a build and extract whatever information you want and then expose that as a new model via the Tooling API. But if one of the existing models solves your use case, I’d rather go with that :wink:

5

Grails 3 uses the custom model builder approach. This is an example: https://github.com/grails/grails-core/blob/0b1350c/grails-gradle-plugin/src/main/groovy/org/grails/gradle/plugin/model/GrailsClasspathToolingModelBuilder.groovy#L42-L46 .