I am looking for a way to lazily configure

Configuration.extendsFrom

in the context of the java-module-testing plugin. Maybe someone here has a smart idea. _Context_: The use case is that the plugin strongly connects a "source-set-under-test" (e.g.

main

,

foo

) and a "test-source-set" (e.g

test

,

fooTest

) for "whitebox" testing in the context of JPMS. In that approach, the production code and test code are treated as "one Module", as if they were packaged into one Jar, to break the otherwise strict package visibility of JPMS. Consequentially, all dependencies I define for the "source-set-under-test" should automatically be available for the "test-source-set". This can be configured like this:

configurations {
    testFooImplementation { extendsFrom(configurations.fooImplementation.get()) }
    testFooRuntimeOnly { extendsFrom(configurations.fooRuntimeOnly.get()) }
    testFooCompileOnly { extendsFrom(configurations.fooCompileOnly.get()) }
}

The plugin performs a default configuration for all existing test suites, assuming that the "source-set-under-test" is

main

as that is the most common case. Now I can reconfigure that if needed (but that's currently broken):

javaModuleTesting.whitebox(testing.suites["fooTest"]) {
   sourcesUnderTest = sourceSets["foo"] // change from 'main' to 'foo'
}

I am looking for a solution to where to place the

extendsFrom

code such that it only uses the finally configured

sourcesUnderTest

. I am not aware of a hook I can use for that, but maybe I miss something. In the past there existed an (internal)

Configuration.beforeLocking

I believe. Something like that would be useful. The only two (bad) ideas I have right now are: 1. Add the

extendsFrom

directly when a

sourcesUnderTest

is configured. If is is reconfigured, undo what was done before by resetting the whole extends-from-set (

setExtendsFrom(...)

). This feels quite unstable if users do their own extednsFrom configuration on top. 2. Use

afterEvaluate

, but there is no guarantee that that is "late enough". I don't like that. I also would need to do some things fundamentally different in how the

whitebox

configuration action is processed in the plugin which feels like a step backwards.