Stop recommending that mods depend on an optional dependency via runtimeOnly

[lukebemish]

Currently, the MDK has an example dependency, commented out, on JEI using compileOnly and runtimeOnly. It is implied that this is an optional dependency, both as JEI is normally an optional dependency and because implementation is not used. However, the use of runtimeOnly does not create an optional dependency; runtimeOnly adds a dependency to both runtimeClasspath (what gets used in dev to run the game) and runtimeElements (the dependencies you publish, in a pom or module metadata, as "I need these at runtime"). This means that any mod depending on a mod that depends on JEI this way will attempt to pull in JEI at runtime as a transitive dependency! This was not an issue with old forgegradle, as fg.deobf stripped all transitive dependencies, but it is an issue now and the MDK should recommend good practice. As an optional dependency, it should be added only to runtimeClasspath, which must be done through another configuration as runtimeClasspath cannot have dependencies directly declared. This PR solves this in the correct way.

[lukebemish]

Note: this really is something where the MDK ought to display good practice, as I have seen mods out in the wild copying what the MDK does for this type of dependency and so publishing bad transitive runtime dependencies which get pulled in by anything trying to depend on them.

[marchermans]

What are we actually trying to achieve here?
As far as I understand it, the optional dependencies should not really be exposed on publication anyway correct?

As such I think adding them as a run dependency, instead of a configuration is the better approach. Is it not?

[Matyrobbrt]

Mods cannot be declared as run dependencies, as that sets them up on the wrong layer. And runtimeOnly is transitive for consumers of your artifact.

[lukebemish]

What maty said; plus, run-specific dependencies are confusing when people are used to dependencies in the dependencies block, and runtime-local dependencies should not be an "advanced" thing by any means. The run-specific dependency block seems primarily meant for being fed into the task that generated the minecraft classpath; that's not the issue here, the issue is preventing publishing of something where depending on it normally is just fine.

[marchermans]

What maty said; plus, run-specific dependencies are confusing when people are used to dependencies in the dependencies block, and runtime-local dependencies should not be an "advanced" thing by any means. The run-specific dependency block seems primarily meant for being fed into the task that generated the minecraft classpath; that's not the issue here, the issue is preventing publishing of something where depending on it normally is just fine.

Yes and I agree that this is the correct solution.
However, the simplest thing for runtime-local dependencies, is the mods folder. Don't you agree?

[lukebemish]

No, I don't agree. These aren't "I want this in dev for convenience" dependencies, these are "I'm compiling against this and need to test with it" dependencies. If you're declaring a gradle dep on it to compile against it, you want to be able to use gradle for the testing dependency too. Beyond that -- you can't/shouldn't commit the mods folder to git. People want their optional dependencies on git so that if they clone the repo fresh, it's good to go

[shartte]

However, the simplest thing for runtime-local dependencies, is the mods folder. Don't you agree?

I hope you are not suggesting that I download JEI, EMI, Curios and REI by hand and place them there 👀