CC-Tweaked/settings.gradle.kts

pluginManagement {
    repositories {
        gradlePluginPortal()
        maven("https://maven.minecraftforge.net")
        maven("https://maven.parchmentmc.org")
    }
    resolutionStrategy {
        eachPlugin {
            if (requested.id.id == "org.spongepowered.mixin") {
                useModule("org.spongepowered:mixingradle:${requested.version}")
            }
        }
    }
}

val mcVersion: String by settings
rootProject.name = "cc-tweaked-$mcVersion"

include(":core-api")
include(":core")

include(":mc-stubs")
include(":forge-stubs")
include(":common-api")
include(":forge-api")

include(":lints")
include(":web")

for (project in rootProject.children) {
    project.projectDir = file("projects/${project.name}")
}
Some "improvements" to our Gradle script - Switch to plugins { ... } imports for Forge (FG finally supports it!) - Use FG's new fg.component to clean up our Maven metadata instead. We also mark JEI as optional (using Gradle's registerFeature), which means we've no stray deps inside our POM any more. 2022-06-19 10:21:41 +00:00			`pluginManagement {`
			`repositories {`
			`gradlePluginPortal()`
			`maven("https://maven.minecraftforge.net")`
			`maven("https://maven.parchmentmc.org")`
			`}`
			`resolutionStrategy {`
			`eachPlugin {`
			`if (requested.id.id == "org.spongepowered.mixin") {`
			`useModule("org.spongepowered:mixingradle:${requested.version}")`
			`}`
			`}`
			`}`
			`}`

Convert build script to Kotlin - Add a new Node plugin. This automatically installs npm dependencies and provides a "NpxExecToDir" to dir task. This allows us to make the doc website task dependencies a little nicer, by simply chaining tasks together, rather than doing dependsOn + `input.files(the other task output)`. - Switch over to CurseForgeGradle from CurseGradle. The latter is super clunky to use in non-Groovy languages. - Copy our Modrinth description body to our repo, and add support for syncing it. We'll still have to do CF manually I think. 2022-10-22 20:09:08 +00:00			`val mcVersion: String by settings`
			`rootProject.name = "cc-tweaked-$mcVersion"`
Move the core API into a separate module It should be possible to consume the ComputerCraft's core (i.e. non-Minecraft code) in other projects, such as emulators. While this has been possible for years, it's somewhat tricky from a maintenance perspective - it's very easy to accidentally add an MC dependency somewhere! By publishing a separate "core" jar, we can better distinguish the boundaries between our Lua runtime and the Minecraft-specific code. Ideally we could have one core project (rather than separate core and core-api modules), and publish a separate "api" jar, like we do for the main mod. However, this isn't really possible to express using Maven dependencies, and so we must resort to this system. Of course, this is kinda what the Java module system is meant to solve, but unfortunately getting that working with Minecraft is infeasible. 2022-11-04 21:41:59 +00:00
			`include(":core-api")`
Move dan200.computercraft.core into a separate module This is a very big diff in changed files, but very small in actual changes. 2022-11-04 22:31:56 +00:00			`include(":core")`
Move our public API into separate modules This adds two new modules: common-api and forge-api, which contain the common and Forge-specific interfaces for CC's Minecraft-specific API. We add a new PlatformHelper interface, which abstracts over some of the loader-specific functionality, such as reading registries[^1] or calling Forge-specific methods. This interface is then implemented in the main mod, and loaded via ServiceLoaders. Some other notes on this: - We now split shared and client-specific source code into separate modules. This is to make it harder to reference client code on the server, thus crashing the game. Eventually we'll split the main mod up too into separate source sets - this is, of course, a much bigger problem! - There's currently some nastiness here due to wanting to preserve binary compatibility of the API. We'll hopefully be able to remove this when 1.19.3 releases. - In order to build a separate Forge-specific API jar, we compile the common sources twice: once for the common jar and once for the Forge jar. Getting this to play nicely with IDEs is a little tricky and so we provide a cct.inlineProject(...) helper to handle everything. [^1]: We /can/ do this with vanilla's APIs, but it gives a lot of deprecation warnings. It just ends up being nicer to abstract over it. 2022-11-06 15:07:13 +00:00
			`include(":mc-stubs")`
			`include(":forge-stubs")`
			`include(":common-api")`
			`include(":forge-api")`

Make the main mod non-null by default This was actually much more work than I thought it would be. Tests pass, but I'm sure there's some regressions in here. 2022-11-09 18:58:31 +00:00			`include(":lints")`
Move website source/build logic to projects/web Mostly useful as it moves some of our build logic out of the main project, as that's already pretty noisy! 2022-11-06 13:37:07 +00:00			`include(":web")`
Move the core API into a separate module It should be possible to consume the ComputerCraft's core (i.e. non-Minecraft code) in other projects, such as emulators. While this has been possible for years, it's somewhat tricky from a maintenance perspective - it's very easy to accidentally add an MC dependency somewhere! By publishing a separate "core" jar, we can better distinguish the boundaries between our Lua runtime and the Minecraft-specific code. Ideally we could have one core project (rather than separate core and core-api modules), and publish a separate "api" jar, like we do for the main mod. However, this isn't really possible to express using Maven dependencies, and so we must resort to this system. Of course, this is kinda what the Java module system is meant to solve, but unfortunately getting that working with Minecraft is infeasible. 2022-11-04 21:41:59 +00:00
			`for (project in rootProject.children) {`
			`project.projectDir = file("projects/${project.name}")`
			`}`