Prastiwar

To add more context I typically just copy the new gradle version and build.gradle from MDK and adjust it from version to version. This time I just backported to the previous gradle version and just updated the forge version in build.gradle (so also not using the process task feature) and it works now. This issue seems to be some bug with gradle and forge that does not lookup the dependency for some reason.

Hello, I need assistance with forge mods porting from 1.19 to 1.20.1. I've created 2 forge mods - mod1 - is a client and server mod (kind of library and client-side tweaks) - mod2 - is server-only mod mod2 references interface API from mod1, so I have a mod1.jar in .`/libs` and in `build.gradle` I included repositories { // Put repositories for dependencies here // ForgeGradle automatically adds the Forge maven and Maven Central for you // If you have mod jar dependencies in ./libs, you can declare them as a repository like so. // See https://docs.gradle.org/current/userguide/declaring_repositories.html#sub:flat_dir_resolver flatDir { dir 'libs' } } dependencies { // Specify the version of Minecraft to use. // Any artifact can be supplied so long as it has a "userdev" classifier artifact and is a compatible patcher artifact. // The "userdev" classifier will be requested and setup by ForgeGradle. // If the group id is "net.minecraft" and the artifact id is one of ["client", "server", "joined"], // then special handling is done to allow a setup of a vanilla dependency without the use of an external repository. minecraft "net.minecraftforge:forge:${minecraft_version}-${forge_version}" // implementation fileTree(dir: 'libs', include: '*.jar') implementation fileTree('libs') // Example mod dependency with JEI - using fg.deobf() ensures the dependency is remapped to your development mappings // The JEI API is declared for compile time use, while the full JEI artifact is used at runtime // compileOnly fg.deobf("mezz.jei:jei-${mc_version}-common-api:${jei_version}") // compileOnly fg.deobf("mezz.jei:jei-${mc_version}-forge-api:${jei_version}") // runtimeOnly fg.deobf("mezz.jei:jei-${mc_version}-forge:${jei_version}") // Example mod dependency using a mod jar from ./libs with a flat dir repository // This maps to ./libs/coolmod-${mc_version}-${coolmod_version}.jar // The group id is ignored when searching -- in this case, it is "blank" // implementation fg.deobf("blank:coolmod-${mc_version}:${coolmod_version}") // For more info: // http://www.gradle.org/docs/current/userguide/artifact_dependencies_tutorial.html // http://www.gradle.org/docs/current/userguide/dependency_management.html } (have only this mod1.jar there anyway). Also, have a mandatory dependency of mod1 in mods.toml in mod2. All this worked fine from 1.12 to 1.19 while porting one version to another over the past years with not much issues. Now I'm porting these from 1.19 to 1.20.1 and got it to compile. How I test these: mod2.jar after successful build lands to local forge server in /mods together with mod1.jar. On my mc client, I put mod1.jar into /mods. Ok, so I run server and client, test functionality manually and get a runtime error java.lang.NoSuchMethodError with a stack trace where I reference the mod1 API interface method within mod2. What could be the issue? I've tried to use implementation fg.deobf('com.me.mod1:mod1:1.20.1') line in dependencies instead fileTree, but it still fails despite the successful compilation and build. Let me know if you need more information.