Run Setup task issues when using different sourceset

[Elec332]

Sorry, I couldn't come up with a short better title.

Say you have your mod source in the main SourceSet, but you want to run something else in another SourceSet,
in this case you can create a run configuration and make it's xxxImplementation configuration extend implementation

See below for an extremely minimalistic example (It crashes after start because there are no compiled classes, but that's not the point)

plugins {
    id 'java-library'
    id 'net.neoforged.gradle.userdev' version '7.0.97'
}

java.toolchain.languageVersion = JavaLanguageVersion.of(17)

sourceSets {

    modRun {
        java.setSrcDirs([])
        resources.setSrcDirs([])
    }

}

runs {
    client {
        modSource sourceSets.modRun
    }
}

configurations {
    modRunImplementation.extendsFrom implementation
}

dependencies {
    implementation "net.neoforged:neoforge:${neo_version}"
}

This will launch (and then crash as mentioned above) without issues.
However, if we move the configurations block below the dependencies block it will not launch .
Not because the dependencies aren't there, but because the following tasks aren't executed before run (The last one is the main issue)
neoFormJoined_xxx_DownloadAssets neoFormJoined_xxx_ExtractNatives writeMinecraftClasspathClient

From a quick look it looks like this is because neoforge detectes when neoforge is added as a dep and then does fancy stuff around it. This is of course not triggered if a configuration want to inherit another one after this happened.

Side point:
Currently you need to use

configurations {
    modRunImplementation.extendsFrom implementation
}

to make modRun work as a valid launch target, but theoretically you'd want the following to be enough:

configurations {
    modRunRuntimeClassPath.extendsFrom runtimeClasspath
}

[marchermans]

That is correct and sadly working as intended.
Due to the way configurations work (and how they actually hold the dependency object) we cannot support the detection and processing purely on the runtime classpath.

There are some ideas in the community on how to resolve this (it would involve walking the entire dependency tree of any given configuration, which could be costly), but for right now we have decided not to implement this.

You can consider it working as intended for now.
I will leave this ticket open so that I don't forget to look into better analysis options for dependency finding in the future

[marchermans]

I think an upcoming version will fix this.

[marchermans]

Added a test to validate that this is actually working now, will be working with newest version.