When viewing the source of a CyclopsCore method from Eclipse in another project, they contain SRG names instead of MCP names. (This actually appears to be the case for all of the Cyclops mods.) For example, if you open IntegratedDynamics-Compat and look at org.cyclops.cyclopscore.item.ItemBlockMetadata, the addInformation function will be called func_77624_a. I know this is an issue with us specifically, because it doesn't happen to non-Cyclops mods. For example, when looking at RFTools from IntegratedDynamics-Compat, mcjty.rftools.blocks.shield.ShieldBlock's addInformation function is still called addInformation.

Shouldn't be a problem anymore with the new mojmappings.

Someting to look into. Perhaps the source jar is created too late.

Are you sure you're checking the RFTools sources? And not just the decompiled JAR?

Are you sure you're checking the RFTools sources? And not just the decompiled JAR?

Yes, it includes the comments.

Just spent some time trying to resolve this, without any luck.
Tried the following:

• Changing the order of artifacts
• Disabling signing
• Disabling javadoc

Something must be changing the sourceJar task, or moving it to a point in the execution where the code has already been obfuscated.

This needs some further investigation.

Actually, I think that our Maven sources are supposed to include the SRG names, and they're just showing up when we look because of how we include them in Gradle. When I make this change to Integrated Dynamics, the problem goes away:

diff --git a/gradle/forge.gradle b/gradle/forge.gradle
index a92d949..b056306 100644
--- a/gradle/forge.gradle
+++ b/gradle/forge.gradle
@@ -10,9 +10,9 @@ repositories {
 dependencies {
     // Add something like 'cyclopscore_version_local=0.1.0-DEV' to your gradle.properties if you want to use a custom local CyclopsCore version.
     if(project.hasProperty("cyclopscore_version_local")) {
-        compile "org.cyclops.cyclopscore:CyclopsCore:${config.minecraft_version}-${project.cyclopscore_version_local}:deobf"
+        deobfCompile "org.cyclops.cyclopscore:CyclopsCore:${config.minecraft_version}-${project.cyclopscore_version_local}"
     } else {
-        compile "org.cyclops.cyclopscore:CyclopsCore:${config.minecraft_version}-${config.cyclopscore_version}:deobf"
+        deobfCompile "org.cyclops.cyclopscore:CyclopsCore:${config.minecraft_version}-${config.cyclopscore_version}"
     }
     // Add something like 'integrateddynamicscompat_version_local=0.1.0-DEV' to your gradle.properties if you want to use a custom local Integrated Dynamics Compat version.
     if(project.hasProperty("integrateddynamicscompat_version_local")) {

Does making that change everywhere seem like a good way to fix this?

The idea of the obfuscated source jar is that when you use it, it will get deobfuscated to whatever version of the MCP mappings that your project uses, rather than being stuck with the version that was used when the jar was built.

Perhaps we could add a setting to gradle.properties that lets you control whether or not my suggested fix is active. Then you (and anyone else using IDEA to code two mods at once) could have it off, and I (and anyone else not doing that) could have it on.

Can a locally-built CC version not just point at your actual source directory for the source in IDEA? Eclipse lets you set it up to do that.

I would think deobfuscation would happen on the main jar, but you may be right.

I'm not a fan of that option. It would still not resolve the problem when using a locally-built CC version, which would occur primarily during development.

I have tried may things before, my current workflow is the most convenient one for me. In the past, this was not possible in IDEA, things might have changed by now, not sure.

https://github.com/MinecraftForge/ForgeGradle/blob/FG_2.3/src/main/java/net/minecraftforge/gradle/user/UserBasePlugin.java#L214-L229 looks like as good of a place as any to start looking if you want to explore this further.

GitHub

MinecraftForge/ForgeGradle

ForgeGradle - Minecraft mod development framework used by Forge and FML for the gradle build system

Ok, so it's the intended functionality of FG. Not sure in what scenarios anyone would ever need an obfuscated source jar though...

So the options to advance I see are:

1. Request a change in FG to not obfuscate source jars
2. Make or own deobfSourceJar task.
3. Ignore this issue

2 is probably the best solution, but would also involve the most effort.