Home > other >  IntelliJ confuses Gradle dependency with different project - still works
IntelliJ confuses Gradle dependency with different project - still works

Time:10-06

The situation: I have two separate Gradle projects imported in IntelliJ idea. Both projects use a framework called Mason. Project A was imported first and has no issues, it uses the newer Version of Mason, which is stored locally in a folder, called 'lib', as Mason.20.jar (none of the Mason versions used here are on Maven Central). Project B was imported later and uses an older Version, which is stored in a folder, also called 'lib', as Mason.19.jar (some elements are not compatible with Mason.20). Both projects are structured the same way and both have the library folder as "Root/lib/", however otherwise the two projects are fully independent from each other and don't even reference each other.

The actual issue: IntelliJ now has issues evaluating Project B, because it looks for the "Mason.20.jar" in "ProjectB/lib/Mason.20.jar", even though it's not referenced anywhere in Project B's build.gradle file. And the project itself is also totally fine, I can run the Gradle tasks without any issue, in and outside of IntelliJ. This issue also only came up after I recently setup my Laptop.

I tried the Gradle sync button from IntelliJ and checked if the dependencies where messed up, but couldn't find anything. I'm guessing that IntelliJ just mixes up the caches from the two Projects, but I have no idea how to fix that.

This is the Gradle task I use to generate the jar file for Project B and also where the error supposedly lies:

task distribute(type: Jar){
    from sourceSets.main.output
    from (configurations.compile.collect {zipTree(it)}){ <--this is where IntelliJ complains
        exclude 'META-INF/MANIFEST.MF'
        exclude 'META-INF/*.SF'
        exclude 'META-INF/*.DSA'
        exclude 'META-INF/*.RSA'
    }

    manifest {
        attributes 'Main-Class': project.mainClassName
    }

    doLast{
        copy {
            from "/build/libs/"
            from "./logging.properties"
            into "./jar"
        }
        copy {
            from "./parameters"
            into "./jar/parameters"
        }
        copy{
            from "./README.txt"
            into "./jar"
            }

        copy{
            from "./batch/"
            into "./jar/batch"
        }

        file(new File(projectDir, "/build")).deleteDir()
        file(new File(projectDir, "/jar/batch/linux/buildJar")).delete()
        file(new File(projectDir, "/jar/batch/windows/buildJar.bat")).delete()
    }
}

And for comparison the equivalent Gradle task for Project A:

task distribute(type: Jar){
outputs.upToDateWhen { false }
    from sourceSets.main.output
    from (configurations.compile.collect {zipTree(it)}){
        exclude 'META-INF/MANIFEST.MF'
        exclude 'META-INF/*.SF'
        exclude 'META-INF/*.DSA'
        exclude 'META-INF/*.RSA'
    }

    manifest {
        attributes 'Main-Class': project.mainClassName
    }

    doLast {
        copy {
            from "/build/libs/"
            into "./jar"
        }
        copy {
            from "./Config"
            into "./jar/Config"
        }
        copy{
            from "./README.txt"
            into "./jar"
            }
        copy {
            from "./scriptfiles"
            into "./jar/scriptfiles"
        }

        file(new File(projectDir, "/build")).deleteDir()
    }
}

Any ideas how to fix this?

CodePudding user response:

After a bit of trying around I found a Solution more or less. It seems IntelliJ might not have been the issue, but Gradle itself. After I manually deleted the Gradle cache located under: %USERPROFILE%\.gradle\caches the issue was gone and even after I switched back to Project A in IntelliJ (did not re-import it and also did not yet build it) it still worked fine. However I don't know how it would behave if I re-import a Project. One thing to Note is that Project A uses a newer Version of the Library in Question, so it might be more reliable to import the project with an older Library first. It might also have been just a random one-time bug.

  • Related