Conversation
|
Is missing config from fabric cli, I would convert to a draft but there seems to be no option to do that from the GitHub mobile app. |
modmuss50
left a comment
There was a problem hiding this comment.
Also update the CLI and add it to the test script here: https://github.com/FabricMC/fabricmc.net/blob/main/cli/test.ts and run the tests to make sure this works on all versions.
scripts/src/lib/template/templates/gradle/kotlin/settings.gradle.kts.eta
Show resolved
Hide resolved
scripts/src/lib/template/templates/gradle/kotlin/gradle.properties.eta
Outdated
Show resolved
Hide resolved
scripts/src/lib/template/templates/gradle/kotlin/build.gradle.kts.eta
Outdated
Show resolved
Hide resolved
scripts/src/lib/template/templates/gradle/kotlin/build.gradle.kts.eta
Outdated
Show resolved
Hide resolved
scripts/src/lib/template/templates/gradle/kotlin/build.gradle.kts.eta
Outdated
Show resolved
Hide resolved
scripts/src/lib/template/templates/gradle/kotlin/build.gradle.kts.eta
Outdated
Show resolved
Hide resolved
scripts/src/lib/template/templates/gradle/groovy/build.gradle.eta
Outdated
Show resolved
Hide resolved
4b6ad86 to
a3258a3
Compare
This reverts commit 4bac270. Will create a separate PR for this patch after the Kotlin DSL has been merged.
036e148 to
4c4ef68
Compare
4c4ef68 to
f7f1f86
Compare
Changes property access to use Gradle property providers instead of project property binding. Using Gradle properties in this way avoids issues when using Isolated Projects (gradle/gradle#32398). An alternative is to use `project.property(...)` instead, which is closer to the Groovy variant but does exhibit these issues.
Shares the gradle.properties.eta file between the Groovy and Kotlin DSL build script types.
|
|
||
| // Fabric API. This is technically optional, but you probably want it anyway. | ||
| <% if (it.unobfuscated) { %>implementation<% } else { %>modImplementation<% } %>("net.fabricmc.fabric-api:fabric-api:${providers.gradleProperty("fabric_api_version").get()}") | ||
| <% if (it.kotlin) { %><% if (it.unobfuscated) { %>implementation<% } else { %>modImplementation<% } %>("net.fabricmc:fabric-language-kotlin:${providers.gradleProperty("fabric_kotlin_version").get()}")<% } %> |
There was a problem hiding this comment.
General thought about these dep strings: I wonder if
modImplementation("net.fabricmc:fabric-language-kotlin:" + providers.gradleProperty("fabric_kotlin_version").get())would be cleaner/easier to read than
modImplementation("net.fabricmc:fabric-language-kotlin:${providers.gradleProperty("fabric_kotlin_version").get()}")I'm fine with either in any case.
There was a problem hiding this comment.
Yeah it might be, it's closer to the groovy version like this though
There was a problem hiding this comment.
kotlin idioms. use string templating not concatenation
There was a problem hiding this comment.
also, if you're going to use providers, you may as well use .map {} instead of immediately resolving it. otherwise just use property("...")
There was a problem hiding this comment.
property is being avoided to work around some issues relating to Isolated Projects. But yeah, mapping is a good idea.
scripts/src/lib/template/templates/gradle/kotlin/settings.gradle.kts.eta
Show resolved
Hide resolved
scripts/src/lib/template/templates/gradle/kotlin/build.gradle.kts.eta
Outdated
Show resolved
Hide resolved
| tasks.withType<JavaCompile>().configureEach { | ||
| options.release = <%= it.java.release %> | ||
| } | ||
| <% if (it.kotlin) { %> | ||
| kotlin { | ||
| compilerOptions { | ||
| jvmTarget = JvmTarget.JVM_<%= it.java.compatibility %> | ||
| } | ||
| } | ||
| <% } %> | ||
| java { | ||
| // Loom will automatically attach sourcesJar to a RemapSourcesJar task and to the "build" task | ||
| // if it is present. | ||
| // If you remove this line, sources will not be generated. | ||
| withSourcesJar() | ||
|
|
||
| sourceCompatibility = JavaVersion.VERSION_<%= it.java.compatibility %> | ||
| targetCompatibility = JavaVersion.VERSION_<%= it.java.compatibility %> | ||
| } |
There was a problem hiding this comment.
| tasks.withType<JavaCompile>().configureEach { | |
| options.release = <%= it.java.release %> | |
| } | |
| <% if (it.kotlin) { %> | |
| kotlin { | |
| compilerOptions { | |
| jvmTarget = JvmTarget.JVM_<%= it.java.compatibility %> | |
| } | |
| } | |
| <% } %> | |
| java { | |
| // Loom will automatically attach sourcesJar to a RemapSourcesJar task and to the "build" task | |
| // if it is present. | |
| // If you remove this line, sources will not be generated. | |
| withSourcesJar() | |
| sourceCompatibility = JavaVersion.VERSION_<%= it.java.compatibility %> | |
| targetCompatibility = JavaVersion.VERSION_<%= it.java.compatibility %> | |
| } | |
| java { | |
| toolchain { | |
| languageVersion = JavaLanguageVersion.of(<%= it.java.compatibility %>) | |
| } | |
| // Loom will automatically attach sourcesJar to a RemapSourcesJar task and to the "build" task | |
| // if it is present. | |
| // If you remove this line, sources will not be generated. | |
| withSourcesJar() | |
| } |
There was a problem hiding this comment.
This is a breaking change as it forces gradle to use a specific JDK version instead of configuring the target of the active toolchain. Should probably be a separate PR if you wish to change this.
|
Going to merge this, if there are any future suggestions/improvements they can always be done later. |

Unlike the other PR, this one tries to stay as similar as possible to the Groovy build script.
The only big difference is the loom version being set in the
settings.gradle.ktsfile.