I have a configuration containing a single dependency which has transitive dependencies. Now, I have a situation where I need to obtain the jar file of the single dependency. I used to do it via

config.files(config.dependencies.single())

but

Configuration#files(Dependency...)

is deprecated now and the message suggests to use incoming.artifactView with componentFilter. So I guess it would be something like this:

val dependency = config.dependencies.single()

val file = config.incoming.artifactView { componentFilter { (it is ModuleComponentIdentifier) && it.group == dependency.group && it.module == dependency.name } }

Is that correct? Is it also correct that the code I have won't work with e.g. a ProjectDependency? Is there a different approach that would support any kind of dependency?

Make another configuration that extends it and is non-transitive.

This doesn't seem to work, I get:

> Expected configuration ':detachedConfiguration1' files to contain exactly one file, however, it contains no files.

This is the code:

val pluginConfig = project.configurations.detachedConfiguration()
    .extendsFrom(backendConfig.get())
    .setTransitive(false)

result.add("--plugin=de.itemis.mps.buildbackends.remigrate::" + pluginConfig.incoming.files.singleFile)

Because a detached configuration cannot extend an attached one

why not? and why doesn't Gradle complain about it then?

thanks for the link! 8.10 is a bit too advanced for me at this point (moving from 7.6.4 to 8.8 at the moment and actually a bit worried because some users are probably still going to be on Gradle 7 or earlier 8.x).

8.10 surely is too advanced, even 8.9 is not released yet. 😄

Does extending a configuration guarantee consistent resolution? Or is there any other advantage vs creating a detached configuration from a copy of all dependencies like this?

project.configurations.detachedConfiguration(*backendConfig.get().allDependencies.toTypedArray())

(I'd like to avoid an attached configuration because it then unnecessarily participates in dependency locking when lockAllConfigurations() is used.)

I see, I don't use locking and never version ranges, so I don't hit such quirks.

I'm afraid that the resolved versions of the two configurations could potentially diverge then and lead to difficult-to-find bugs.

The potential for diverged versions should not be different and imho should be 0 I guess

Well it's Murphy... if it can happen, it eventually will. But okay, I'll use an attached configuration. Thank you for your help.

Yeah, I love Murphy, even have a book about him. But I really don't think it can happen. Maybe with some resolution strategy or somesuch. But then an attached would probably even have higher probability to end up with the same version.

Technically two configurations with the same dependencies could diverge as repositories could be defined with content filtering based on the configuration, or they could be configured differently (force, exclude, etc.). If you want to be extra-sure, then use an artifact view or look into the

resolvedConfiguration.firstLevelModuleDependencies

or similar APIs.

I wanted to use an artifact view originally but it seems that it would only work with module dependencies so any local experiments with e.g. using included builds and/or project dependencies instead of a module dependency wouldn't work, IIUC.

Project dependencies are module dependencies (https://docs.gradle.org/current/javadoc/org/gradle/api/artifacts/ProjectDependency.html), just not "external module" dependencies 😉