[1.10.2]Adding mods to dev environment but not depending on them

[Bregor]

Is it possible to add other mods to the development environment via build.gradle from a maven repository, but not depend on them in the mod iteself.

 

The reason for this is that I want to have some mods to test my blocks with in the dev environment, but they are no dependencies of the mod, more like development conveniences. Yet it would be nice if the mods have not to be manually restored everywhere i check out the mod repository.

[Animefan8888]

I'm not sure, but I think in 1.10 you may just be able to put them in the mods folder?

[Bregor]

Any idea how this can be done from a maven repository via gradle?

[Animefan8888]

What do you mean do you want to be able to edit them or just have them load then forge loads?

[Ernio]

In 1.9+ you can just throw (even obfuscated) mods into /mods/ or add them as library in eclipse. They will be loaded as normal mods (gameplay). You could also see their source if you'd attach it in eclipse.

 

I don't see how maven/gradle plays role here.

[Choonster]

  On 8/3/2016 at 2:07 AM, Bregor said:

Is it possible to add other mods to the development environment via build.gradle from a maven repository, but not depend on them in the mod iteself.

 

The reason for this is that I want to have some mods to test my blocks with in the dev environment, but they are no dependencies of the mod, more like development conveniences. Yet it would be nice if the mods have not to be manually restored everywhere i check out the mod repository.

 

Just add them as dependencies through Gradle. Your mod won't require them at runtime unless you use classes from them.

 

You can also add them as

deobfProvided

/

deobfCompile

dependencies to have ForgeGradle deobfuscate them on-disk. See the MDK's build.gradle for more details.

[Bregor]

  On 8/3/2016 at 8:10 AM, Choonster said:

Just add them as dependencies through Gradle. Your mod won't require them at runtime unless you use classes from them.

 

You can also add them as

deobfProvided

/

deobfCompile

dependencies to have ForgeGradle deobfuscate them on-disk. See the MDK's build.gradle for more details.

 

I have successfully added them this way.

 

There are just two things I don't fully understand yet:

• What is the difference between deobfProvided and deobfCompile (or can I even use runtime like in the jei example: runtime "mezz.jei:jei_${mcversion}{jei_version}")?
  
• It seems if I add a new mod dependency to build.grade, run setupDecompWorkspace, refresh all Gradle Projects in IntelliJ, run MC - I need to repeat this one or two times until the mod finally loads in the MC client.
  

[Choonster]

  On 8/3/2016 at 11:20 PM, Bregor said:

• What is the difference between deobfProvided and deobfCompile (or can I even use runtime like in the jei example: runtime "mezz.jei:jei_${mcversion}{jei_version}")?

 

Theoretically,

compile

is for dependencies that are required at both compile-time and runtime and

provided

is for dependencies that are required at compile-time but optional at runtime. Practically, I'm not sure if there's any difference between the two in terms of Forge modding.

 

deobfCompile

and

deobfProvided

are the same as

compile

and

provided

, but ForgeGradle will deobfuscate them on disk.

 

If you add a mod as a non-

deobf

dependency, its source code will be obfuscated when you view it in your IDE and it will only be deobfuscated at runtime.

 

  Quote

• It seems if I add a new mod dependency to build.grade, run setupDecompWorkspace, refresh all Gradle Projects in IntelliJ, run MC - I need to repeat this one or two times until the mod finally loads in the MC client.

 

I haven't experienced this myself, I'm not sure what would cause it or how to fix it.