deobfCompile does not work with ivy dependencies or local files

[mezz]

repositories {
    ivy {
        name "Aroma1997Core"
        artifactPattern "http://addons-origin.cursecdn.com/files/2232/553/[module]-${mcversion}-[revision].[ext]"
    }
}

dependencies {
    deobfCompile group: "aroma1997.core", name: 'Aroma1997Core', version: "1.0.3.4.b36", ext: 'jar'
}

This correctly creates a deobf jar with sources in C:\Users\<me>\.gradle\caches\minecraft\deobfedDeps\deobf\aroma1997\core\Aroma1997Core\1.0.3.4.b36\Aroma1997Core-1.0.3.4.b36.jar

but gradle and the idea project are linked to the obfuscated version here:
C:\Users\<me>\.gradle\caches\modules-2\files-2.1\aroma1997.core\Aroma1997Core\1.0.3.4.b36\3e5d3cf3c577cd48e1ba6d3e6f68af42281f078c\Aroma1997Core-1.0.3.4.b36.jar

and compilation (./gradlew build) fails.
gradle.log

[modmuss50]

this also does not work when you want to use local files

[williewillus]

any news on this? some mods we use as a dependencies don't provide maven and if they're compiled against older mappings it breaks the workspace and holds the dependent back on old mappings as well

[LexManos]

you can always create a local maven as its purely a flat file system.
The deobf system hacks deeply to replace the deps and we're not looking into expanding it to other systems.

[AbrarSyed]

There are reasons for this.

1. If you have the jar in hand, pass it through BON2 or something, why do you need FG to do it for you?
2. Ivy dependencies have indeterminate amounts of metadata, only maven dependencies for sure give me the info I need. This info includes transitive deps, as well as locations of sourcejars and stuff that need deobfuscating.

Reason I needed the maven info was so I could put the deobfuscated jars into a local maven repo in correct locations and have them grabbed by FG. If you use flatfile deps with gradle, it doesnt grab sourcejars or javadocs. Ivy dependencies dont have a specific location format and cant be converted to maven deps reliably.

[mezz]

For context, the case we are running into is dependencies that have a "standard" distribution url but no maven.
Baubles is one example where people have asked for a maven for a long time with no response.

The only workaround is to use BON2, which is much less convenient than automatically downloading and setting up dependencies with gradle.
It seems counter-intuitive that we can simply point BON2 at a jar but we can't do the same with FG.

[AbrarSyed]

gradle is very powerful.. If you are having it auto-downlaod your dependency, you can also have it auto-deobfusctae the dependency with BON. https://docs.gradle.org/current/dsl/org.gradle.api.tasks.JavaExec.html

If you are using Ivy.. well.. thats a bit of a problem.

[mezz]

Ivy is the only way I know of to download a jar from a url (like from Curse).
Is there another way?

[Mumfrey]

You can actually do this by using the output of a task as a dependency in the compile configuration, you need to create a configuration to contain your ivy dependency and then gradle is actually smart enough to create a task graph which will include the task which runs BON (which includes the ivy dep as its input) in the execution strategy. I do this in one of my own projects in order to download a dependency and then relocate it before using it in the classpath of my project. The structure looks like this:

[DaemonUmbra]

Closing this issue as it does not appear to be applicable to the currently supported ForgeGradle branch (FG_3.0).

If I am incorrect in this regard, please create a new issue prefixed with [FG_3.0] and containing:

• A summary of the issue (in case the issue has mutated slightly or the original report was poorly described)
• Steps to recreate the issue
• Console output or logs (if possible)

Note that an ongoing effort to update legacy MinecraftForge branches to utilize FG_3.0 is ongoing and accepting informed contributions. (For more information join the Discord and read through the #mcpconfig channel)