PlumyGames / mgpp

The next generation of Mindustry modding.
https://plumygames.github.io/mgpp/
GNU General Public License v3.0
48 stars 3 forks source link

A module can't apply mgpp in a multi-module project #13

Closed liplum closed 2 years ago

liplum commented 2 years ago

Context

In its the build.gradle.kts, I added some dependencies from other modules in my while project.

plugins {
    kotlin("jvm")
    id("com.google.devtools.ksp") version "1.7.0-1.0.6"
    `maven-publish`
    id("io.github.liplum.mgpp")
}
...
dependencies {
    implementation(project(":annotations"))
    implementation(project(":lib"))
    testImplementation("org.junit.jupiter:junit-jupiter-api:5.8.2")
    testRuntimeOnly("org.junit.jupiter:junit-jupiter-engine:5.8.2")
}

Problem

When I sync the gradle in my Intellij IDEA, the problem was ocurred.

Build file 'E:\MyProject\Mindustry\CyberIO\lib\build.gradle.kts' line: 2

An exception occurred applying plugin request [id: 'org.jetbrains.kotlin.jvm', version: '1.6.21']
> Failed to apply plugin 'org.jetbrains.kotlin.jvm'.
   > Gradle#projectsEvaluated(Action) on build 'cyberio' cannot be executed in the current context.

* Exception is:
org.gradle.api.plugins.InvalidPluginException: An exception occurred applying plugin request [id: 'org.jetbrains.kotlin.jvm', version: '1.6.21']
...
at io.github.liplum.mindustry.MindustryJavaPlugin$apply$1$2$1.invoke(Plugins.kt:453)
    at io.github.liplum.mindustry.MindustryJavaPlugin$apply$1$2$1.invoke(Plugins.kt:275)
    at io.github.liplum.dsl.KtDslSupportKt$sam$i$org_gradle_api_Action$0.execute(KtDslSupport.kt)
    at org.gradle.api.internal.DefaultMutationGuard$2.execute(DefaultMutationGuard.java:44)
    at org.gradle.api.internal.DefaultMutationGuard$2.execute(DefaultMutationGuard.java:44)
    at org.gradle.api.internal.DefaultNamedDomainObjectCollection$ExistingNamedDomainObjectProvider.configure(DefaultNamedDomainObjectCollection.java:853)
    at org.gradle.api.internal.tasks.DefaultTaskCollection$ExistingTaskProvider.configure(DefaultTaskCollection.java:200)
    at org.gradle.api.internal.DefaultNamedDomainObjectCollection.named(DefaultNamedDomainObjectCollection.java:391)
    at org.gradle.api.internal.tasks.DefaultTaskCollection.named(DefaultTaskCollection.java:127)
    at io.github.liplum.mindustry.MindustryJavaPlugin$apply$1$2.invoke(Plugins.kt:452)
    at io.github.liplum.mindustry.MindustryJavaPlugin$apply$1$2.invoke(Plugins.kt:273)
    at io.github.liplum.dsl.DslExtensionsKt.afterEvaluateThis$lambda-1(DslExtensions.kt:99)
    at org.gradle.configuration.internal.DefaultUserCodeApplicationContext$CurrentApplication$1.execute(DefaultUserCodeApplicationContext.java:123)

Caused by: org.gradle.api.internal.AbstractMutationGuard$IllegalMutationException: Gradle#projectsEvaluated(Action) on build 'cyberio' cannot be executed in the current context.
    at org.gradle.api.internal.AbstractMutationGuard.createIllegalStateException(AbstractMutationGuard.java:39)
    at org.gradle.api.internal.AbstractMutationGuard.assertMutationAllowed(AbstractMutationGuard.java:34)
    at org.gradle.invocation.DefaultGradle.assertProjectMutatingMethodAllow

My research

When I comment, aka remove, all implementation dependencies of other modules, such as implementation(project(":annotations")), it's solved. But it's unacceptable, I need them.

liplum commented 2 years ago

I think you're making a dependency chain, or graph, in your whole project. The mindustry.deploy.enableFatJar will decide whether the jar file of :jar task includes all runtime classpaths. So it should be execeuted after project evaluated, which results in the problem. Here is a simple explaination: gradle/gradle#10923 As a workaroud temporarily, since this project you mentioned isn't a mod but a library which servers the actual mod project, you have to add the noFatJar in your mindustry.deploy:

mindustry {
    deploy {
        noFatJar
    }
}

It will disable the fatJar, then you won't receive the error. By the way, I will reconsider a new way for how enableFatJar works.

liplum commented 2 years ago

After the assessment, I just now developed a new way to cope with this likely common situation. If you have many library modules but have only one mod or more projects, you can add this line into your gradle.properties:

mgpp.deploy.enableFatJar=false

This will disable the fat jar as default for each project. Thus, in this way, you have to configure all projects which you want them to include the rumtime classpaths, such as kotlin std-lib, in their build.gradle[.kts], like this:

mindustry {
    deploy {
        fatJar
    }
}