Good morning, I'm currently trying to resolve a project's dependencies in a detachedConfiguration. My goal is to determine what dependencies are currently being exposed as

api

declared dependencies without digging into the buildscript, but instead referring to the resolution. I understand this won't be foolproof. The issue I'm having is that when I try to resolve the current project in a detachedConfiguration, it either fails to resolve, or it doesn't show any exposed dependencies, despite having a

api

dependency on

gson

.

def detached = project.configurations.detachedConfiguration()
def dep = project.dependencies.project(path: ":${project.path}", configuration: detached)
detached.dependencies.add(dep)

Without seeing the error you get, this is mostly guesswork, but I guess the problem is, that you do not set the necessary attributes on your configuration so that the dependencies can be resolved properly. Do you really need that programmatically? If not, it is much easier to either use a build

--scan

, or the

dependencies

task. If this is about investigating whether your dependencies are declared in the "correct" configurations, I recommend using the https://github.com/autonomousapps/dependency-analysis-gradle-plugin

Yeah. I'd like a programmatic way. I've reviewed this project many times, sadly though it doesn't support the version of Java we use here, and last I knew, there was no plan for backwards support in this plugin.

You mean you use a version of Java older than 11?

🤔 So we could technically run Gradle in Java 11 while continuing to build our product in a lower version?

Exactly, that's what JVM toolchains are for

Would the idea here be to set the default toolchain to JDK 11, then configure our CompileJava tasks to use the lower version? Is there an approach that we could make the default our lower and then specify Gradle's (basically the vice-versa)? I was looking at that page, but I only see an approach that handles the default to 11.

No, the toolchain you define is what you need for your project code (instead of setting things like

release

,

sourceCompatibility

, or

targetCompatibility

). For the Java 11, you just ensure that you run Gradle with Java 11. In Gradle 8.8 is a new incubating feature that you can indeed also use a discovered toolchain for running Gradle.

Ah, gotcha. Sounds good. Reason I was asking is to try to 'prefer' our lower version since our CI server doesn't currently support 11 afaik. But I guess whatever java default is set up there will be picked, but I doubt we'll want to push this plugin into our buildscripts.

The "configuration: detached" in your original snippet is wrong. You ask "give me the configuration with name 'myProjectdetachedConfiguration1' from the project" and the error is telling you of course that a configuration with that name does not exist. Remove the "configuration: detached".

Removing that brings back the resolution error - I've redacted my project name, but the gray blocks represent

:myProject

Maybe you cannot depend on the project from a detached configuration. It is detached. 🤷‍♂️ Never tried such a thing

That's what I was trying at first, but I couldn't find anything in the Gradle API that denoted a dependency being an exposed

api

dependency while debugging. I don't see anything that would represent that, but I know sometimes my debugger doesn't report all available objects for some reason.

api

is not a resolvable configuration, so you cannot directly resolve it. If you want to know what is only in

api

or the configurations it extends, you probably have to add a new resolvable configuration that only extends from

api

and has the necessary attributes set.

I have it working now, and I guess I technically don't need to know what dependencies are being resolved when a dependency is declared under the

api

configuration, rather I just need to know what dependencies are declared in the

api

configuration. This became much more trivial:

project.configurations.named(JavaPlugin.API_CONFIGURATION_NAME).get().dependencies

Btw. once you migrated to it, it exposes also its analysis results and intermediate results afair, so you can also use the information from it for some custom visualization.