Use compileOnly scope instead of compile for Minecraft and Forge dependencies

[Cypher121]

According to Gradle's notes on the compileOnly scope (https://blog.gradle.org/introducing-compile-only-dependencies), one of the use-cases for it is as follows:

Dependencies whose API is required at compile time but whose implementation is to be provided by a consuming library, application or runtime environment.

Last part fits forge dependency for mods perfectly.

As it stands right now, every library and mod declares forge as a compile dependency, which means 2 things:

• It is declared a transitive dependency, causing mods to add it in addition to its own version of forge, unless one of them is explicitly removed.
• It is declared a runtime dependency, which somewhat confusingly means mods are expected to provide it themselves at runtime. That means shadow jar will by default attempt to include forge and all of its dependencies in the mod. That behavior is not easy to avoid, as it is supposed to be avoided by having dependency marked compileOnly

Please consider putting moving the minecraft configuration from compile to compileOnly.

P.S. https://docs.gradle.org/current/userguide/java_library_plugin.html#sec:java_library_configurations_graph is a good reference on how dependency scopes are set up for java projects. Note that compile and runtime scopes are not there at all, as they have been deprecated since Gradle 3.0

[Niko-sk2x]

Except that using compile only dependency here means that IDEs won't add Forge and Minecraft to run classpath. Because it's expected to be provided by something else.

While it's technically correct, it's a very useless kind of correct, because it would make it very hard to actually run mods in dev environment. The linked documentation even explicitly states that compileOnly dependencies won't be included in runtime classpath. And for the mentioned use case:

    Dependencies required at compile time but never required at runtime, such as source-only annotations or annotation processors;
    Dependencies required at compile time but required at runtime only when using certain features, a.k.a. optional dependencies;
    Dependencies whose API is required at compile time but whose implementation is to be provided by a consuming library, application or runtime environment.

While it technically fits the last one, I think it definitely goes the intention that can be seen in the previous 2 use cases.

And yes some IDEs have an option to include "provided" dependency scope in run classpath. But this means it would no longer be possible to have other mods as compileOnly dependency.

It's far easier to just get around shadowJar defaults once, than it is to get around IDEs each time you set up dev environment.

[Cypher121]

Yeah, I agree, compileOnly is pretty stupid in how it conflates compile-only and provided together. However, in this case it's not an issue as there's already an intermediate configuration that FG provides called minecraft, which can be added to the runtime classpath in this case, basically making it mean 'provided'.

And so far, the only ways to bypass shadowJar adding forge that I found were either moving minecraft configuration from extending compile to extending compileOnly (which is basically what this issue is about), or excluding forge and every single transitive dependency it and minecraft bring in, cause there are no transitive exclusions in shadow.

You tell me what's easier.

[Niko-sk2x]

I honestly haven't yet played around with shadowJar in 1.13. But generally the way I used shadowjar is by defining my own shadow configuration and give all dependencies in that one configration to shadowJar, excluding everything else.

And while you should add forge to runtime classpath manually, at least intellij won't pick it up. Intellij goes with which configurations a dependency is in, and not gradle's runtime/compile classpath. I don't use eclipse so I can't say how it will be there. If you aren't using the eclipse gradle plugin, it's probably a non-issue. But I expect the same issues with eclipse gradle plugin.

[Cypher121]

Okay, looks like Idea does in fact ignore runtimeClasspath, while gradle sometimes puts 2 forges on classpath. Weird behavior all around.

And yes, I suppose it's possible to define another configuration just for shadowed artifacts. But shadow is not the only problem with this approach.

Another problem is exactly what compile means. It's been deprecated because it has a very strange meaning: a compile dependency, a runtime dependency and part of the public API all at once. That also means that using a project with a compile dependency on forge as a dependency in another project will attempt to pull that version of Forge as a dependency. This also applies to maven POMs: unless authors go through their pom and delete the forge_mapped_snapshot a compile dependency puts there, using libraries will cause errors like these:

Another solution I see is not to mess with dependency configurations behind the scenes at all and to simply provide dependency-creating functions, so that they are used as

dependencies {
    implementation forge(minecraft: '1.13.2', version: '25.0.84')
    api deobf('some.group:library:0.0.1') //don't force compile on people here either
}

That might be a more elegant and standard way to do it, although leaves some small room for misconfiguration, like, idk, putting forge in runtimeOnly. It'll also make it clear what dependencies go where, for both IDEs and plugins like shadow or maven-publish, while letting users customize it if something is not according to their wishes without knowing too much about FG's internals.

[Niko-sk2x]

From what I remember (and now verified by looking at old discord messages from amadorness) something like what you describe (configuration forge(somethingHere)) was originally the way it was supposed to be done, or at least that's the way I understood how it's going to be. But apparently something has changed.

[Cypher121]

from what I was told on the forge discord, that was the plan for at least deobf, but never happened due to time constraints. That's definitely a solution that suits me, though, so I could try implementing it, if there's no reason to avoid that kind of configuration.

[LexManos]

"Another solution I see is not to mess with dependency configurations behind the scenes at all and to simply provide dependency-creating functions, so that they are used as" This was Ama's original idea, but he fucked off for 6 months and never got it done. So i did what I could. And I am not digging into gradle's internals any deeper to figure out how to do that crap.

At the end of the day this doesn't need discussion, PR or shush.

[mezz]

Go ahead with a PR @Cypher121, that would be the ideal solution.
IMO start small with just deobf so that you don't have too many changes in a single PR.