From mobile apps to microservices, from small startups to big enterprises, Gradle helps teams build, automate and deliver better software, faster.

Gradle Community

hm, good question.
Just guessing, but maybe you could create another configuration, extend it from `testRuntimeClasspath`, resolve it, lookup the version, remove it again.
(detached will not work as detached currently cannot extend from named)

A tricky idea, but I will give it a try, thanks

Assuming it will not try to resolve also a configuration being extended :⁠-⁠\

If I use it directly in apply:

```        Configuration testImplementation = project.configurations.findByName("testImplementation")  //how to can configuration for extendsFrom in lazy way with named?
        Configuration tmpTestImplementation = project.configurations.maybeCreate("tmpTestImplementation").extendsFrom(testImplementation)
        Set&lt;File&gt; deps = tmpTestImplementation.resolve()
       log.warn("deps: " + deps.size())

```
 
I observe:
```Cannot change dependencies of dependency configuration ':implementation' after it has been included in dependency resolution.```

Well, even if it worked, it would be too soon.
As you see something later tries to add something.

You should probably not do it directly in `apply`, but in the `withDependencies`?

Because then `testRuntimeOnly` will also be marked as being part in resolution and you cannot add the new dependency

I'm out of ideas then right now.
Short of instead copying over the dependencies and traversing up the extendsFrom and copying over also those dependencies, so that the configuration is not considered having been used in resolution.
But I don't know whether this will work and whether it is supported API, if API exists at all.
But even if it works, directly in `apply` will still be too soon, as then the user or other plugins did not have a chance to configure the dependencies.

Yes, I believe I also had some other problems when using it with withDependencies, but anyway, thanks to your suggestion with artifacts copying (configuration.copy() was copying too much), I was able to achieve that:
 <https://github.com/szpak/gradle-pitest-plugin/pull/353|https://github.com/szpak/gradle-pitest-plugin/pull/353>

Thanks again and I hope, someone will have some less complex idea to achieve the same. In Maven it was much easier :wink: