mirrors/CC-Tweaked
1
0
Fork 0
mirror of https://github.com/SquidDev-CC/CC-Tweaked synced 2024-11-10 20:09:58 +00:00
Code Issues Releases Wiki Activity
fc834cd97f
CC-Tweaked/gradle/libs.versions.toml

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

187 lines
9.1 KiB
TOML
Raw Normal View History

License CC:T according to the REUSE specification (#1351) This adds SPDX license headers to all source code files, following the REUSE[1] specification. This does not include any asset files (such as generated JSON files, or textures). While REUSE does support doing so with ".license" files, for now we define these licences using the .reuse/dep5 file. [1]: https://reuse.software/
2023-03-15 21:52:13 +00:00
# SPDX-FileCopyrightText: 2022 The CC: Tweaked Developers
#
# SPDX-License-Identifier: MPL-2.0
Fix several off-by-one issues in UploadFileMessage We now fuzz UploadFileMessage, generating random files and checking they round-trip correctly. The joy of having a long-lasting refactor branch with an absolutely massive diff, is that you end up spotting bugs, and then it's a massive pain to merge the fix back into trunk!
2022-10-21 22:10:18 +00:00
[versions]
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
# Minecraft
# MC version is specified in gradle.properties, as we need that in settings.gradle.
Bump dependency versions Mostly in prep for 1.19.4. - Update to Loom 1.1. - Simplifies our handling of remapped configurations a little. - Removes the need for a fake fabric.mod.json in the API jar. For reasons I don't quite understand, this required us to bump the Fabric API version. Otherwise interfaces are not injected. - Update to Rollup 3.0. - Do NOT update NullAway: It now correctly checks @Nullable fields in inherited classes. This is good, but also a pain as Minecraft is a little over-eager in where it puts @Nullable.
2023-03-14 18:41:31 +00:00
# Remember to update corresponding versions in fabric.mod.json/mods.toml
Update to 1.20.4
2024-01-31 20:55:14 +00:00
fabric-api = "0.93.1+1.20.4"
fabric-loader = "0.15.3"
neoForge = "20.4.142-beta"
neoForgeSpi = "8.0.1"
Fabric lol - Add support for Fabric. This is mostly pretty simple, though does require a lot more mixins than Forge. Half this diff is due to data generators: we run them separately as some aspects (recipes mostly) are different between the loaders. - Add integration with Iris (same as our Oculus support) and REI (mostly the same as our JEI support). - Generic peripherals only support inventories (or rather InventoryStorage) right now. Supporting more of the Fabric storage API is going to be tricky due to the slotted nature of the API: maybe something to revisit after Transfer API V3 (V4?, I've lost track). Note, this does /not/ mean I will be publishing a Fabric version of CC:T. My plan is to rebase CC:R on top of this, hopefully simplifying the maintenance work on their end and making the two mods a little more consistent.
2022-11-10 19:32:13 +00:00
mixin = "0.8.5"
Update to 1.20.4
2024-01-31 20:55:14 +00:00
parchment = "2023.12.31"
parchmentMc = "1.20.3"
yarn = "1.20.4+build.3"
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
Improve our version tooling - Add a check to ensure declared dependencies in the :core project, and those inherited from Minecraft are the same. - Compute the next Cobalt version, rather than specifying it manually. - Add the gradle versions plugin (and version catalog update), and update some versions.
2023-12-19 18:12:21 +00:00
# Core dependencies (these versions are tied to the version Minecraft uses)
Update to 1.20.4
2024-01-31 20:55:14 +00:00
fastutil = "8.5.12"
guava = "32.1.2-jre"
netty = "4.1.97.Final"
slf4j = "2.0.7"
Improve our version tooling - Add a check to ensure declared dependencies in the :core project, and those inherited from Minecraft are the same. - Compute the next Cobalt version, rather than specifying it manually. - Add the gradle versions plugin (and version catalog update), and update some versions.
2023-12-19 18:12:21 +00:00
# Core dependencies (independent of Minecraft)
asm = "9.6"
autoService = "1.1.1"
checkerFramework = "3.42.0"
Update Cobalt to 0.9.0 - Debug hooks are now correctly called for every function. - Fix several minor inconsistencies with debug.getinfo. - Fix Lua tables being sized incorrectly when created from varargs.
2024-01-27 09:59:04 +00:00
cobalt = "0.9.0"
Improve our version tooling - Add a check to ensure declared dependencies in the :core project, and those inherited from Minecraft are the same. - Compute the next Cobalt version, rather than specifying it manually. - Add the gradle versions plugin (and version catalog update), and update some versions.
2023-12-19 18:12:21 +00:00
commonsCli = "1.6.0"
jetbrainsAnnotations = "24.1.0"
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
jsr305 = "3.0.2"
Bundle jzlib with our published jar Netty requires this for handling compressed websockets with non-default compression arguments. Closes #1394
2023-03-29 08:30:29 +00:00
jzlib = "1.1.3"
Improve our version tooling - Add a check to ensure declared dependencies in the :core project, and those inherited from Minecraft are the same. - Compute the next Cobalt version, rather than specifying it manually. - Add the gradle versions plugin (and version catalog update), and update some versions.
2023-12-19 18:12:21 +00:00
kotlin = "1.9.21"
kotlin-coroutines = "1.7.3"
Generic dependency update A couple of changes caused by checkstyle being a little more strict.
2023-08-31 18:14:37 +00:00
nightConfig = "3.6.7"
Fix several off-by-one issues in UploadFileMessage We now fuzz UploadFileMessage, generating random files and checking they round-trip correctly. The joy of having a long-lasting refactor branch with an absolutely massive diff, is that you end up spotting bugs, and then it's a massive pain to merge the fix back into trunk!
2022-10-21 22:10:18 +00:00
Improve packaging of published jars - Publish javadoc again: for now this is just the common-api - Remove all dependencies from the published Forge jar. This is technically not needed (fg.deobf does this anyway), but seems sensible.
2022-11-08 16:43:27 +00:00
# Minecraft mods
Update to 1.20.4
2024-01-31 20:55:14 +00:00
emi = "1.0.30+1.20.4"
Merge branch 'mc-1.19.x' into mc-1.20.x
2023-08-27 18:08:59 +00:00
fabricPermissions = "0.3.20230723"
Update to 1.20.4
2024-01-31 20:55:14 +00:00
iris = "1.6.14+1.20.4"
jei = "16.0.0.28"
modmenu = "9.0.0"
Add back MoreRed support I removed this in aa0d544bbac13dfff6736634c6ef9ac72f0d6cbe, way back in late 2021. Looks like it's been updating in the meantime and I hadn't noticed, so add it back. I've simplified the code a little bit, to make use of our new capability helpers, but otherwise it's almost exactly the same :D.
2023-08-27 23:04:46 +00:00
moreRed = "4.0.0.4"
Improve packaging of published jars - Publish javadoc again: for now this is just the common-api - Remove all dependencies from the published Forge jar. This is technically not needed (fg.deobf does this anyway), but seems sensible.
2022-11-08 16:43:27 +00:00
oculus = "1.2.5"
Update to 1.20.4
2024-01-31 20:55:14 +00:00
rei = "14.0.688"
Add a system for client-side tests (#1219) - Add a new ClientJavaExec Gradle task, which is used for client-side tests. This: - Copies the exec spec from another JavaExec task. - Sets some additional system properties to configure on gametest framework. - Runs Java inside an X framebuffer (when available), meaning we don't need to spin up a new window. We also configure this task so that only one instance can run at once, meaning we don't spawn multiple MC windows at once! - Port our 1.16 client test framework to 1.19. This is mostly the same as before, but screenshots no longer do a golden test: they /just/ write to a folder. Screenshots are compared manually afterwards. This is still pretty brittle, and there's a lot of sleeps scattered around in the code. It's not clear how well this will play on CI. - Roll our own game test loader, rather than relying on the mod loader to do it for us. This ensures that loading is consistent between platforms (we already had to do some hacks for Forge) and makes it easier to provide custom logic for loading client-only tests. - Run several client tests (namely those involving monitor rendering) against Sodium and Iris too. There's some nastiness here to set up new Loom run configurations and automatically configure Iris to use Complementary Shaders, but it's not too bad. These tests /don't/ run on CI, so it doesn't need to be as reliable.
2022-11-18 23:57:25 +00:00
rubidium = "0.6.1"
Update library versions Everything has updated to 1.20.1 now, so we can start depending on things again :).
2023-07-10 19:50:32 +00:00
sodium = "mc1.20-0.4.10"
Improve packaging of published jars - Publish javadoc again: for now this is just the common-api - Remove all dependencies from the published Forge jar. This is technically not needed (fg.deobf does this anyway), but seems sensible.
2022-11-08 16:43:27 +00:00
Fix several off-by-one issues in UploadFileMessage We now fuzz UploadFileMessage, generating random files and checking they round-trip correctly. The joy of having a long-lasting refactor branch with an absolutely massive diff, is that you end up spotting bugs, and then it's a massive pain to merge the fix back into trunk!
2022-10-21 22:10:18 +00:00
# Testing
hamcrest = "2.2"
Improve our version tooling - Add a check to ensure declared dependencies in the :core project, and those inherited from Minecraft are the same. - Compute the next Cobalt version, rather than specifying it manually. - Add the gradle versions plugin (and version catalog update), and update some versions.
2023-12-19 18:12:21 +00:00
jqwik = "1.8.2"
junit = "5.10.1"
Fix several off-by-one issues in UploadFileMessage We now fuzz UploadFileMessage, generating random files and checking they round-trip correctly. The joy of having a long-lasting refactor branch with an absolutely massive diff, is that you end up spotting bugs, and then it's a massive pain to merge the fix back into trunk!
2022-10-21 22:10:18 +00:00
Use spotless for enforcing licenses It's more verbose as the default license plugin doesn't support multiple license headers. However, it also gives us some other goodies (namely formatting Kotlin and removing unused imports), so worth doing.
2022-10-22 16:47:39 +00:00
# Build tools
Add abstract classes for our generic peripherals This commit adds abstract classes to describe the interface for our mod-loader-specific generic peripherals (inventories, fluid storage, item storage). This offers several advantages: - Javadoc to illuaminate conversion no longer needs the Forge project (just core and common). - Ensures we have a consistent interface between Forge and Fabric. Note, this does /not/ implement fluid or energy storage for Fabric. We probably could do fluid without issue, but not something worth doing right now.
2023-11-22 18:20:15 +00:00
cctJavadoc = "1.8.2"
Improve our version tooling - Add a check to ensure declared dependencies in the :core project, and those inherited from Minecraft are the same. - Compute the next Cobalt version, rather than specifying it manually. - Add the gradle versions plugin (and version catalog update), and update some versions.
2023-12-19 18:12:21 +00:00
checkstyle = "10.12.6"
Update to 1.20.4
2024-01-31 20:55:14 +00:00
curseForgeGradle = "1.1.18"
Improve our version tooling - Add a check to ensure declared dependencies in the :core project, and those inherited from Minecraft are the same. - Compute the next Cobalt version, rather than specifying it manually. - Add the gradle versions plugin (and version catalog update), and update some versions.
2023-12-19 18:12:21 +00:00
errorProne-core = "2.23.0"
Generic dependency update A couple of changes caused by checkstyle being a little more strict.
2023-08-31 18:14:37 +00:00
errorProne-plugin = "3.1.0"
Update Gradle to 8.5 - Update FG to 6.0.20 - no major changes, but required for the Gradle update. - Update Loom to 1.5.x - this adds Vineflower support by default, so we can remove loom-vineflower.
2024-01-27 09:28:12 +00:00
fabric-loom = "1.5.7"
Improve our version tooling - Add a check to ensure declared dependencies in the :core project, and those inherited from Minecraft are the same. - Compute the next Cobalt version, rather than specifying it manually. - Add the gradle versions plugin (and version catalog update), and update some versions.
2023-12-19 18:12:21 +00:00
githubRelease = "2.5.2"
gradleVersions = "0.50.0"
Generic dependency update A couple of changes caused by checkstyle being a little more strict.
2023-08-31 18:14:37 +00:00
ideaExt = "1.1.7"
Build a web-based emulator for the documentation site (#1597) Historically we've used copy-cat to provide a web-based emulator for running example code on our documentation site. However, copy-cat is often out-of-date with CC:T, which means example snippets fail when you try to run them! This commit vendors in copy-cat (or rather an updated version of it) into CC:T itself, allowing us to ensure the emulator is always in sync with the mod. While the ARCHITECTURE.md documentation goes into a little bit more detail here, the general implementation is as follows - In project/src/main we implement the core of the emulator. This includes a basic reimplementation of some of CC's classes to work on the web (mostly the HTTP API and ComputerThread), and some additional code to expose the computers to Javascript. - This is all then compiled to Javascript using [TeaVM][1] (we actually use a [personal fork of it][2] as there's a couple of changes I've not upstreamed yet). - The Javascript side then pulls in the these compiled classes (and the CC ROM) and hooks them up to [cc-web-term][3] to display the actual computer. - As we're no longer pulling in copy-cat, we can simplify our bundling system a little - we now just compile to ESM modules directly. [1]: https://github.com/konsoletyper/teavm [2]: https://github.com/SquidDev/teavm/tree/squid-patches [3]: https://github.com/squiddev-cc/cc-web-term
2023-10-03 08:19:19 +00:00
illuaminate = "0.1.0-44-g9ee0055"
Improve our version tooling - Add a check to ensure declared dependencies in the :core project, and those inherited from Minecraft are the same. - Compute the next Cobalt version, rather than specifying it manually. - Add the gradle versions plugin (and version catalog update), and update some versions.
2023-12-19 18:12:21 +00:00
lwjgl = "3.3.3"
Update to 1.20.4
2024-01-31 20:55:14 +00:00
minotaur = "2.8.7"
neoGradle = "7.0.85"
Switch the core-api to be non-null by default We'll do this everywhere eventually, but much easier to do it incrementally: - Use checker framework to default all field/methods/parameters to @Nonnull. - Start using ErrorProne[1] and NullAway[2] to check for possible null pointer issues. I did look into using CheckerFramework, but it's much stricter (i.e. it's actually Correct). This is technically good, but is a much steeper migration path, which I'm not sure we're prepared for yet! [1]: https://github.com/google/error-prone [2]: https://github.com/uber/NullAway
2022-11-06 10:28:49 +00:00
nullAway = "0.9.9"
Improve our version tooling - Add a check to ensure declared dependencies in the :core project, and those inherited from Minecraft are the same. - Compute the next Cobalt version, rather than specifying it manually. - Add the gradle versions plugin (and version catalog update), and update some versions.
2023-12-19 18:12:21 +00:00
spotless = "6.23.3"
Bump dependency versions Mostly in prep for 1.19.4. - Update to Loom 1.1. - Simplifies our handling of remapped configurations a little. - Removes the need for a fake fabric.mod.json in the API jar. For reasons I don't quite understand, this required us to bump the Fabric API version. Otherwise interfaces are not injected. - Update to Rollup 3.0. - Do NOT update NullAway: It now correctly checks @Nullable fields in inherited classes. This is good, but also a pain as Minecraft is a little over-eager in where it puts @Nullable.
2023-03-14 18:41:31 +00:00
taskTree = "2.1.1"
Fix several issues with the web emulator - Bump TeaVM version to fix issues with locales and our "export" generation. - Fix TComputerThread not requeuing correctly.
2023-11-15 13:12:31 +00:00
teavm = "0.10.0-SQUID.2"
Switch to our own Gradle plugin for vanilla Minecraft I didn't make a new years resolution to stop writing build tooling, but maybe I should have. This replaces our use of VanillaGradle with a new project, VanillaExtract. This offers a couple of useful features for multi-loader dev, including Parchment and Unpick support, both of which we now use in CC:T.
2024-01-29 20:59:16 +00:00
vanillaExtract = "0.1.1"
Improve our version tooling - Add a check to ensure declared dependencies in the :core project, and those inherited from Minecraft are the same. - Compute the next Cobalt version, rather than specifying it manually. - Add the gradle versions plugin (and version catalog update), and update some versions.
2023-12-19 18:12:21 +00:00
versionCatalogUpdate = "0.8.1"
Use spotless for enforcing licenses It's more verbose as the default license plugin doesn't support multiple license headers. However, it also gives us some other goodies (namely formatting Kotlin and removing unused imports), so worth doing.
2022-10-22 16:47:39 +00:00
Fix several off-by-one issues in UploadFileMessage We now fuzz UploadFileMessage, generating random files and checking they round-trip correctly. The joy of having a long-lasting refactor branch with an absolutely massive diff, is that you end up spotting bugs, and then it's a massive pain to merge the fix back into trunk!
2022-10-21 22:10:18 +00:00
[libraries]
Improve packaging of published jars - Publish javadoc again: for now this is just the common-api - Remove all dependencies from the published Forge jar. This is technically not needed (fg.deobf does this anyway), but seems sensible.
2022-11-08 16:43:27 +00:00
# Normal dependencies
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
asm = { module = "org.ow2.asm:asm", version.ref = "asm" }
Build a web-based emulator for the documentation site (#1597) Historically we've used copy-cat to provide a web-based emulator for running example code on our documentation site. However, copy-cat is often out-of-date with CC:T, which means example snippets fail when you try to run them! This commit vendors in copy-cat (or rather an updated version of it) into CC:T itself, allowing us to ensure the emulator is always in sync with the mod. While the ARCHITECTURE.md documentation goes into a little bit more detail here, the general implementation is as follows - In project/src/main we implement the core of the emulator. This includes a basic reimplementation of some of CC's classes to work on the web (mostly the HTTP API and ComputerThread), and some additional code to expose the computers to Javascript. - This is all then compiled to Javascript using [TeaVM][1] (we actually use a [personal fork of it][2] as there's a couple of changes I've not upstreamed yet). - The Javascript side then pulls in the these compiled classes (and the CC ROM) and hooks them up to [cc-web-term][3] to display the actual computer. - As we're no longer pulling in copy-cat, we can simplify our bundling system a little - we now just compile to ESM modules directly. [1]: https://github.com/konsoletyper/teavm [2]: https://github.com/SquidDev/teavm/tree/squid-patches [3]: https://github.com/squiddev-cc/cc-web-term
2023-10-03 08:19:19 +00:00
asm-commons = { module = "org.ow2.asm:asm-commons", version.ref = "asm" }
Fix several off-by-one issues in UploadFileMessage We now fuzz UploadFileMessage, generating random files and checking they round-trip correctly. The joy of having a long-lasting refactor branch with an absolutely massive diff, is that you end up spotting bugs, and then it's a massive pain to merge the fix back into trunk!
2022-10-21 22:10:18 +00:00
autoService = { module = "com.google.auto.service:auto-service", version.ref = "autoService" }
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
checkerFramework = { module = "org.checkerframework:checker-qual", version.ref = "checkerFramework" }
Update Cobalt to 0.8.0 - Update Cobalt to 0.8.0, switching our Lua version to 5.2(ish). - Remove our `load` wrapper, as we no longer need to inject _ENV into the enviroment table. - Update the parser to handle labels and goto. This doesn't check that gotos are well formed, but at least means the parser doesn't fall over on them. - Update our docs to reflect the changes to Cobalt.
2023-11-08 18:42:17 +00:00
cobalt = { module = "cc.tweaked:cobalt", version.ref = "cobalt" }
Add a standalone CC:T UI Does it count as an emulator when it's official? I hope not, as this'd make it my fourth or fifth emulator at this point. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * Developing/debugging CraftOS is a massive pain to do inside Minecraft, as any change to resources requires a compile+hot swap cycle (and sometimes a `/reload` in-game). As such, it's often more convenient to spin up an emulator, pointing it to load the ROM from CC:T's sources. However, this isn't practical when also making changes to the Java classes. In this case, we either need to go in-game, or build a custom version of CCEmuX. This commit offers an alternative option: we now have our own emulator, which allows us to hot swap both Lua and Java to our heart's content. Most of the code here is based on our monitor TBO renderer. We probably could share some more of this, but there's not really a good place for it - feels a bit weird just to chuck it in :core. This is *not* a general-purpose emulator. It's limited in a lot of ways (won't launch on Mac[^1], no support for multiple computers) - just stick to what's there already. [^1]: We require OpenGL 4.5 due to our use of DSA.
2023-10-28 16:55:56 +00:00
commonsCli = { module = "commons-cli:commons-cli", version.ref = "commonsCli" }
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
fastutil = { module = "it.unimi.dsi:fastutil", version.ref = "fastutil" }
Update to 1.20.4
2024-01-31 20:55:14 +00:00
neoForgeSpi = { module = "net.neoforged:neoforgespi", version.ref = "neoForgeSpi" }
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
guava = { module = "com.google.guava:guava", version.ref = "guava" }
Load the CC API with services loaders This is a little odd (it's more complex for one!), but means we can reuse the internal API interface in other classes, which is useful for the data provider refactor I'm about to do. This is much nicer in Java 17 :D (records, ServiceLoader.stream()), but such is the perils of still targetting 1.16.
2022-10-21 22:50:44 +00:00
jetbrainsAnnotations = { module = "org.jetbrains:annotations", version.ref = "jetbrainsAnnotations" }
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
jsr305 = { module = "com.google.code.findbugs:jsr305", version.ref = "jsr305" }
Bundle jzlib with our published jar Netty requires this for handling compressed websockets with non-default compression arguments. Closes #1394
2023-03-29 08:30:29 +00:00
jzlib = { module = "com.jcraft:jzlib", version.ref = "jzlib" }
Fix several off-by-one issues in UploadFileMessage We now fuzz UploadFileMessage, generating random files and checking they round-trip correctly. The joy of having a long-lasting refactor branch with an absolutely massive diff, is that you end up spotting bugs, and then it's a massive pain to merge the fix back into trunk!
2022-10-21 22:10:18 +00:00
kotlin-coroutines = { module = "org.jetbrains.kotlinx:kotlinx-coroutines-core", version.ref = "kotlin-coroutines" }
Bundle jzlib with our published jar Netty requires this for handling compressed websockets with non-default compression arguments. Closes #1394
2023-03-29 08:30:29 +00:00
kotlin-platform = { module = "org.jetbrains.kotlin:kotlin-bom", version.ref = "kotlin" }
Bump Kotlin version to 1.8
2023-01-17 19:33:49 +00:00
kotlin-stdlib = { module = "org.jetbrains.kotlin:kotlin-stdlib", version.ref = "kotlin" }
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
netty-http = { module = "io.netty:netty-codec-http", version.ref = "netty" }
Add support for proxying HTTP requests (#1461)
2023-06-06 18:58:24 +00:00
netty-socks = { module = "io.netty:netty-codec-socks", version.ref = "netty" }
netty-proxy = { module = "io.netty:netty-handler-proxy", version.ref = "netty" }
Split CC:T into common and forge projects After several weeks of carefully arranging ribbons, we pull the string and end up with, ... a bit of a messy bow. There were still some things I'd missed. - Split the mod into a common (vanilla-only) project and Forge-specific project. This gives us room to add Fabric support later on. - Split the project into main/client source sets. This is not currently statically checked: we'll do that soon. - Rename block/item/tile entities to use suffixes rather than prefixes.
2022-11-09 23:58:56 +00:00
nightConfig-core = { module = "com.electronwill.night-config:core", version.ref = "nightConfig" }
nightConfig-toml = { module = "com.electronwill.night-config:toml", version.ref = "nightConfig" }
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
slf4j = { module = "org.slf4j:slf4j-api", version.ref = "slf4j" }
Fix several off-by-one issues in UploadFileMessage We now fuzz UploadFileMessage, generating random files and checking they round-trip correctly. The joy of having a long-lasting refactor branch with an absolutely massive diff, is that you end up spotting bugs, and then it's a massive pain to merge the fix back into trunk!
2022-10-21 22:10:18 +00:00
Improve packaging of published jars - Publish javadoc again: for now this is just the common-api - Remove all dependencies from the published Forge jar. This is technically not needed (fg.deobf does this anyway), but seems sensible.
2022-11-08 16:43:27 +00:00
# Minecraft mods
Fabric lol - Add support for Fabric. This is mostly pretty simple, though does require a lot more mixins than Forge. Half this diff is due to data generators: we run them separately as some aspects (recipes mostly) are different between the loaders. - Add integration with Iris (same as our Oculus support) and REI (mostly the same as our JEI support). - Generic peripherals only support inventories (or rather InventoryStorage) right now. Supporting more of the Fabric storage API is going to be tricky due to the slotted nature of the API: maybe something to revisit after Transfer API V3 (V4?, I've lost track). Note, this does /not/ mean I will be publishing a Fabric version of CC:T. My plan is to rebase CC:R on top of this, hopefully simplifying the maintenance work on their end and making the two mods a little more consistent.
2022-11-10 19:32:13 +00:00
fabric-api = { module = "net.fabricmc.fabric-api:fabric-api", version.ref = "fabric-api" }
fabric-loader = { module = "net.fabricmc:fabric-loader", version.ref = "fabric-loader" }
Replace Fabric JUnit hacks with fabric-loader-junit Also configure some of our common JUnit run configurations via Gradle - I end up setting these up in every worktree anyway - so let's just do it once.
2023-10-26 21:06:40 +00:00
fabric-junit = { module = "net.fabricmc:fabric-loader-junit", version.ref = "fabric-loader" }
Use permission APIs for the /computercraft command - Add a generic PermissionRegistry interface. This behaves similarly to our ShaderMod interface, searching all providers until it finds a compatible one. We could just make this part of the platform code instead, but this allows us to support multiple systems on Fabric, where things are less standardised. This interface behaves like a registry, rather than a straight `getPermission(node, player)` method, as Forge requires us to list our nodes up-front. - Add Forge (using the built-in system) and Fabric (using fabric-permissions-api) implementations of the above interface. - Register permission nodes for our commands, and use those instead. This does mean that the permissions check for the root /computercraft command now requires enumerating all child commands (and so potential does 7 permission lookups), but hopefully this isn't too bad in practice. - Remove UserLevel.OWNER - we never used this anywhere, and I can't imagine we'll want to in the future.
2023-08-27 11:15:55 +00:00
fabricPermissions = { module = "me.lucko:fabric-permissions-api", version.ref = "fabricPermissions" }
Add EMI compatibility This just adds stack comparisons, so that upgrades are considered (much like JEI and REI). No dynamic recipes, as EMI doesn't support those :(.
2023-07-10 19:31:06 +00:00
emi = { module = "dev.emi:emi-xplat-mojmap", version.ref = "emi" }
Fabric lol - Add support for Fabric. This is mostly pretty simple, though does require a lot more mixins than Forge. Half this diff is due to data generators: we run them separately as some aspects (recipes mostly) are different between the loaders. - Add integration with Iris (same as our Oculus support) and REI (mostly the same as our JEI support). - Generic peripherals only support inventories (or rather InventoryStorage) right now. Supporting more of the Fabric storage API is going to be tricky due to the slotted nature of the API: maybe something to revisit after Transfer API V3 (V4?, I've lost track). Note, this does /not/ mean I will be publishing a Fabric version of CC:T. My plan is to rebase CC:R on top of this, hopefully simplifying the maintenance work on their end and making the two mods a little more consistent.
2022-11-10 19:32:13 +00:00
iris = { module = "maven.modrinth:iris", version.ref = "iris" }
Update to 1.20.4
2024-01-31 20:55:14 +00:00
jei-api = { module = "mezz.jei:jei-1.20.2-common-api", version.ref = "jei" }
jei-fabric = { module = "mezz.jei:jei-1.20.2-fabric", version.ref = "jei" }
jei-forge = { module = "mezz.jei:jei-1.20.2-forge", version.ref = "jei" }
Split CC:T into common and forge projects After several weeks of carefully arranging ribbons, we pull the string and end up with, ... a bit of a messy bow. There were still some things I'd missed. - Split the mod into a common (vanilla-only) project and Forge-specific project. This gives us room to add Fabric support later on. - Split the project into main/client source sets. This is not currently statically checked: we'll do that soon. - Rename block/item/tile entities to use suffixes rather than prefixes.
2022-11-09 23:58:56 +00:00
mixin = { module = "org.spongepowered:mixin", version.ref = "mixin" }
Generate en_us.json via datagen I was originally pretty sceptical about this, but it actually ends up being useful for the same reason any other form of datagen is: we can ensure that names are well formed, and that every string is actually translated. There's some future work here to go through all the custom translation keys and move them into constants (maybe also do something with the /computercraft command?), but that's a separate chunk of work. The main motivation for this is to add translation keys to our config: the Fabric version of Forge Config API provides a config UI, so it's useful to provide user-friendly strings. Our generator also automatically copies comments over, turning them into tooltips. This also updates all of the other language files to match en_us.json again: it's a very noisy diff as the file is now sorted alphabetically. Hopefully this won't affect weblate though [^1]: Amusing really that the Fabric port actually is more useful than the original.
2022-11-20 13:00:43 +00:00
modmenu = { module = "com.terraformersmc:modmenu", version.ref = "modmenu" }
Add back MoreRed support I removed this in aa0d544bbac13dfff6736634c6ef9ac72f0d6cbe, way back in late 2021. Looks like it's been updating in the meantime and I hadn't noticed, so add it back. I've simplified the code a little bit, to make use of our new capability helpers, but otherwise it's almost exactly the same :D.
2023-08-27 23:04:46 +00:00
moreRed = { module = "commoble.morered:morered-1.20.1", version.ref = "moreRed" }
Improve packaging of published jars - Publish javadoc again: for now this is just the common-api - Remove all dependencies from the published Forge jar. This is technically not needed (fg.deobf does this anyway), but seems sensible.
2022-11-08 16:43:27 +00:00
oculus = { module = "maven.modrinth:oculus", version.ref = "oculus" }
Fabric lol - Add support for Fabric. This is mostly pretty simple, though does require a lot more mixins than Forge. Half this diff is due to data generators: we run them separately as some aspects (recipes mostly) are different between the loaders. - Add integration with Iris (same as our Oculus support) and REI (mostly the same as our JEI support). - Generic peripherals only support inventories (or rather InventoryStorage) right now. Supporting more of the Fabric storage API is going to be tricky due to the slotted nature of the API: maybe something to revisit after Transfer API V3 (V4?, I've lost track). Note, this does /not/ mean I will be publishing a Fabric version of CC:T. My plan is to rebase CC:R on top of this, hopefully simplifying the maintenance work on their end and making the two mods a little more consistent.
2022-11-10 19:32:13 +00:00
rei-api = { module = "me.shedaniel:RoughlyEnoughItems-api", version.ref = "rei" }
rei-builtin = { module = "me.shedaniel:RoughlyEnoughItems-default-plugin", version.ref = "rei" }
rei-fabric = { module = "me.shedaniel:RoughlyEnoughItems-fabric", version.ref = "rei" }
Add a system for client-side tests (#1219) - Add a new ClientJavaExec Gradle task, which is used for client-side tests. This: - Copies the exec spec from another JavaExec task. - Sets some additional system properties to configure on gametest framework. - Runs Java inside an X framebuffer (when available), meaning we don't need to spin up a new window. We also configure this task so that only one instance can run at once, meaning we don't spawn multiple MC windows at once! - Port our 1.16 client test framework to 1.19. This is mostly the same as before, but screenshots no longer do a golden test: they /just/ write to a folder. Screenshots are compared manually afterwards. This is still pretty brittle, and there's a lot of sleeps scattered around in the code. It's not clear how well this will play on CI. - Roll our own game test loader, rather than relying on the mod loader to do it for us. This ensures that loading is consistent between platforms (we already had to do some hacks for Forge) and makes it easier to provide custom logic for loading client-only tests. - Run several client tests (namely those involving monitor rendering) against Sodium and Iris too. There's some nastiness here to set up new Loom run configurations and automatically configure Iris to use Complementary Shaders, but it's not too bad. These tests /don't/ run on CI, so it doesn't need to be as reliable.
2022-11-18 23:57:25 +00:00
rubidium = { module = "maven.modrinth:rubidium", version.ref = "rubidium" }
sodium = { module = "maven.modrinth:sodium", version.ref = "sodium" }
Improve packaging of published jars - Publish javadoc again: for now this is just the common-api - Remove all dependencies from the published Forge jar. This is technically not needed (fg.deobf does this anyway), but seems sensible.
2022-11-08 16:43:27 +00:00
Fix several off-by-one issues in UploadFileMessage We now fuzz UploadFileMessage, generating random files and checking they round-trip correctly. The joy of having a long-lasting refactor branch with an absolutely massive diff, is that you end up spotting bugs, and then it's a massive pain to merge the fix back into trunk!
2022-10-21 22:10:18 +00:00
# Testing
hamcrest = { module = "org.hamcrest:hamcrest", version.ref = "hamcrest" }
jqwik-api = { module = "net.jqwik:jqwik-api", version.ref = "jqwik" }
jqwik-engine = { module = "net.jqwik:jqwik-engine", version.ref = "jqwik" }
junit-jupiter-api = { module = "org.junit.jupiter:junit-jupiter-api", version.ref = "junit" }
junit-jupiter-engine = { module = "org.junit.jupiter:junit-jupiter-engine", version.ref = "junit" }
junit-jupiter-params = { module = "org.junit.jupiter:junit-jupiter-params", version.ref = "junit" }
Update to latest Forge This fixes the issue with DeferredRegister crashing on non-wrapped registries.
2022-12-15 17:53:50 +00:00
slf4j-simple = { module = "org.slf4j:slf4j-simple", version.ref = "slf4j" }
Fix several off-by-one issues in UploadFileMessage We now fuzz UploadFileMessage, generating random files and checking they round-trip correctly. The joy of having a long-lasting refactor branch with an absolutely massive diff, is that you end up spotting bugs, and then it's a massive pain to merge the fix back into trunk!
2022-10-21 22:10:18 +00:00
Add a standalone CC:T UI Does it count as an emulator when it's official? I hope not, as this'd make it my fourth or fifth emulator at this point. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * Developing/debugging CraftOS is a massive pain to do inside Minecraft, as any change to resources requires a compile+hot swap cycle (and sometimes a `/reload` in-game). As such, it's often more convenient to spin up an emulator, pointing it to load the ROM from CC:T's sources. However, this isn't practical when also making changes to the Java classes. In this case, we either need to go in-game, or build a custom version of CCEmuX. This commit offers an alternative option: we now have our own emulator, which allows us to hot swap both Lua and Java to our heart's content. Most of the code here is based on our monitor TBO renderer. We probably could share some more of this, but there's not really a good place for it - feels a bit weird just to chuck it in :core. This is *not* a general-purpose emulator. It's limited in a lot of ways (won't launch on Mac[^1], no support for multiple computers) - just stick to what's there already. [^1]: We require OpenGL 4.5 due to our use of DSA.
2023-10-28 16:55:56 +00:00
# LWJGL
lwjgl-bom = { module = "org.lwjgl:lwjgl-bom", version.ref = "lwjgl" }
lwjgl-core = { module = "org.lwjgl:lwjgl" }
lwjgl-opengl = { module = "org.lwjgl:lwjgl-opengl" }
lwjgl-glfw = { module = "org.lwjgl:lwjgl-glfw" }
Move some more build logic to buildSrc Look, I don't enjoy having 600 LOC long build.gradle files, it's just very easy to do! This at least moves some of the complexity elsewhere, so the build script is a little more declarative.
2022-10-22 19:47:47 +00:00
# Build tools
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
cctJavadoc = { module = "cc.tweaked:cct-javadoc", version.ref = "cctJavadoc" }
Move some more build logic to buildSrc Look, I don't enjoy having 600 LOC long build.gradle files, it's just very easy to do! This at least moves some of the complexity elsewhere, so the build script is a little more declarative.
2022-10-22 19:47:47 +00:00
checkstyle = { module = "com.puppycrawl.tools:checkstyle", version.ref = "checkstyle" }
Publish Fabric jars to CF/Modrinth Like all publishing code, we'll only find out if it works when we run it!
2023-03-15 23:20:07 +00:00
curseForgeGradle = { module = "net.darkhax.curseforgegradle:CurseForgeGradle", version.ref = "curseForgeGradle" }
Switch the core-api to be non-null by default We'll do this everywhere eventually, but much easier to do it incrementally: - Use checker framework to default all field/methods/parameters to @Nonnull. - Start using ErrorProne[1] and NullAway[2] to check for possible null pointer issues. I did look into using CheckerFramework, but it's much stricter (i.e. it's actually Correct). This is technically good, but is a much steeper migration path, which I'm not sure we're prepared for yet! [1]: https://github.com/google/error-prone [2]: https://github.com/uber/NullAway
2022-11-06 10:28:49 +00:00
errorProne-annotations = { module = "com.google.errorprone:error_prone_annotations", version.ref = "errorProne-core" }
errorProne-api = { module = "com.google.errorprone:error_prone_check_api", version.ref = "errorProne-core" }
errorProne-core = { module = "com.google.errorprone:error_prone_core", version.ref = "errorProne-core" }
errorProne-plugin = { module = "net.ltgt.gradle:gradle-errorprone-plugin", version.ref = "errorProne-plugin" }
errorProne-testHelpers = { module = "com.google.errorprone:error_prone_test_helpers", version.ref = "errorProne-core" }
Fabric lol - Add support for Fabric. This is mostly pretty simple, though does require a lot more mixins than Forge. Half this diff is due to data generators: we run them separately as some aspects (recipes mostly) are different between the loaders. - Add integration with Iris (same as our Oculus support) and REI (mostly the same as our JEI support). - Generic peripherals only support inventories (or rather InventoryStorage) right now. Supporting more of the Fabric storage API is going to be tricky due to the slotted nature of the API: maybe something to revisit after Transfer API V3 (V4?, I've lost track). Note, this does /not/ mean I will be publishing a Fabric version of CC:T. My plan is to rebase CC:R on top of this, hopefully simplifying the maintenance work on their end and making the two mods a little more consistent.
2022-11-10 19:32:13 +00:00
fabric-loom = { module = "net.fabricmc:fabric-loom", version.ref = "fabric-loom" }
Replace Fabric JUnit hacks with fabric-loader-junit Also configure some of our common JUnit run configurations via Gradle - I end up setting these up in every worktree anyway - so let's just do it once.
2023-10-26 21:06:40 +00:00
ideaExt = { module = "gradle.plugin.org.jetbrains.gradle.plugin.idea-ext:gradle-idea-ext", version.ref = "ideaExt" }
Move some test support code into testFixtues This offers very few advantages now, but helps support the following in the future: - Reuse test support code across multiple projects (useful for multi-loader). - Allow using test fixture code in testMod. We've got a version of our gametest which use Kotlin instead of Lua for asserting computer behaviour. We can't use java-test-fixtures here for Forge reasons, so have to roll our own version. Alas. - Add an ILuaMachine implementation which runs Kotlin coroutines instead. We can use this for testing asynchronous APIs. This also replaces the FakeComputerManager. - Move most things in the .support module to .test.core. We need to use a separate package in order to cope with Java 9 modules (again, thanks Forge).
2022-10-29 17:17:02 +00:00
kotlin-plugin = { module = "org.jetbrains.kotlin:kotlin-gradle-plugin", version.ref = "kotlin" }
Publish Fabric jars to CF/Modrinth Like all publishing code, we'll only find out if it works when we run it!
2023-03-15 23:20:07 +00:00
minotaur = { module = "com.modrinth.minotaur:Minotaur", version.ref = "minotaur" }
Update to 1.20.4
2024-01-31 20:55:14 +00:00
neoGradle-userdev = { module = "net.neoforged.gradle:userdev", version.ref = "neoGradle" }
Switch the core-api to be non-null by default We'll do this everywhere eventually, but much easier to do it incrementally: - Use checker framework to default all field/methods/parameters to @Nonnull. - Start using ErrorProne[1] and NullAway[2] to check for possible null pointer issues. I did look into using CheckerFramework, but it's much stricter (i.e. it's actually Correct). This is technically good, but is a much steeper migration path, which I'm not sure we're prepared for yet! [1]: https://github.com/google/error-prone [2]: https://github.com/uber/NullAway
2022-11-06 10:28:49 +00:00
nullAway = { module = "com.uber.nullaway:nullaway", version.ref = "nullAway" }
Use spotless for enforcing licenses It's more verbose as the default license plugin doesn't support multiple license headers. However, it also gives us some other goodies (namely formatting Kotlin and removing unused imports), so worth doing.
2022-10-22 16:47:39 +00:00
spotless = { module = "com.diffplug.spotless:spotless-plugin-gradle", version.ref = "spotless" }
Build a web-based emulator for the documentation site (#1597) Historically we've used copy-cat to provide a web-based emulator for running example code on our documentation site. However, copy-cat is often out-of-date with CC:T, which means example snippets fail when you try to run them! This commit vendors in copy-cat (or rather an updated version of it) into CC:T itself, allowing us to ensure the emulator is always in sync with the mod. While the ARCHITECTURE.md documentation goes into a little bit more detail here, the general implementation is as follows - In project/src/main we implement the core of the emulator. This includes a basic reimplementation of some of CC's classes to work on the web (mostly the HTTP API and ComputerThread), and some additional code to expose the computers to Javascript. - This is all then compiled to Javascript using [TeaVM][1] (we actually use a [personal fork of it][2] as there's a couple of changes I've not upstreamed yet). - The Javascript side then pulls in the these compiled classes (and the CC ROM) and hooks them up to [cc-web-term][3] to display the actual computer. - As we're no longer pulling in copy-cat, we can simplify our bundling system a little - we now just compile to ESM modules directly. [1]: https://github.com/konsoletyper/teavm [2]: https://github.com/SquidDev/teavm/tree/squid-patches [3]: https://github.com/squiddev-cc/cc-web-term
2023-10-03 08:19:19 +00:00
teavm-classlib = { module = "org.teavm:teavm-classlib", version.ref = "teavm" }
teavm-jso = { module = "org.teavm:teavm-jso", version.ref = "teavm" }
teavm-jso-apis = { module = "org.teavm:teavm-jso-apis", version.ref = "teavm" }
teavm-jso-impl = { module = "org.teavm:teavm-jso-impl", version.ref = "teavm" }
teavm-metaprogramming-api = { module = "org.teavm:teavm-metaprogramming-api", version.ref = "teavm" }
teavm-metaprogramming-impl = { module = "org.teavm:teavm-metaprogramming-impl", version.ref = "teavm" }
teavm-platform = { module = "org.teavm:teavm-platform", version.ref = "teavm" }
teavm-tooling = { module = "org.teavm:teavm-tooling", version.ref = "teavm" }
Switch to our own Gradle plugin for vanilla Minecraft I didn't make a new years resolution to stop writing build tooling, but maybe I should have. This replaces our use of VanillaGradle with a new project, VanillaExtract. This offers a couple of useful features for multi-loader dev, including Parchment and Unpick support, both of which we now use in CC:T.
2024-01-29 20:59:16 +00:00
vanillaExtract = { module = "cc.tweaked.vanilla-extract:plugin", version.ref = "vanillaExtract" }
yarn = { module = "net.fabricmc:yarn", version.ref = "yarn" }
Use spotless for enforcing licenses It's more verbose as the default license plugin doesn't support multiple license headers. However, it also gives us some other goodies (namely formatting Kotlin and removing unused imports), so worth doing.
2022-10-22 16:47:39 +00:00
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
[plugins]
Switch the core-api to be non-null by default We'll do this everywhere eventually, but much easier to do it incrementally: - Use checker framework to default all field/methods/parameters to @Nonnull. - Start using ErrorProne[1] and NullAway[2] to check for possible null pointer issues. I did look into using CheckerFramework, but it's much stricter (i.e. it's actually Correct). This is technically good, but is a much steeper migration path, which I'm not sure we're prepared for yet! [1]: https://github.com/google/error-prone [2]: https://github.com/uber/NullAway
2022-11-06 10:28:49 +00:00
githubRelease = { id = "com.github.breadmoirai.github-release", version.ref = "githubRelease" }
Improve our version tooling - Add a check to ensure declared dependencies in the :core project, and those inherited from Minecraft are the same. - Compute the next Cobalt version, rather than specifying it manually. - Add the gradle versions plugin (and version catalog update), and update some versions.
2023-12-19 18:12:21 +00:00
gradleVersions = { id = "com.github.ben-manes.versions", version.ref = "gradleVersions" }
Switch the core-api to be non-null by default We'll do this everywhere eventually, but much easier to do it incrementally: - Use checker framework to default all field/methods/parameters to @Nonnull. - Start using ErrorProne[1] and NullAway[2] to check for possible null pointer issues. I did look into using CheckerFramework, but it's much stricter (i.e. it's actually Correct). This is technically good, but is a much steeper migration path, which I'm not sure we're prepared for yet! [1]: https://github.com/google/error-prone [2]: https://github.com/uber/NullAway
2022-11-06 10:28:49 +00:00
kotlin = { id = "org.jetbrains.kotlin.jvm", version.ref = "kotlin" }
taskTree = { id = "com.dorongold.task-tree", version.ref = "taskTree" }
Improve our version tooling - Add a check to ensure declared dependencies in the :core project, and those inherited from Minecraft are the same. - Compute the next Cobalt version, rather than specifying it manually. - Add the gradle versions plugin (and version catalog update), and update some versions.
2023-12-19 18:12:21 +00:00
versionCatalogUpdate = { id = "nl.littlerobots.version-catalog-update", version.ref = "versionCatalogUpdate" }
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
Fix several off-by-one issues in UploadFileMessage We now fuzz UploadFileMessage, generating random files and checking they round-trip correctly. The joy of having a long-lasting refactor branch with an absolutely massive diff, is that you end up spotting bugs, and then it's a massive pain to merge the fix back into trunk!
2022-10-21 22:10:18 +00:00
[bundles]
Build a web-based emulator for the documentation site (#1597) Historically we've used copy-cat to provide a web-based emulator for running example code on our documentation site. However, copy-cat is often out-of-date with CC:T, which means example snippets fail when you try to run them! This commit vendors in copy-cat (or rather an updated version of it) into CC:T itself, allowing us to ensure the emulator is always in sync with the mod. While the ARCHITECTURE.md documentation goes into a little bit more detail here, the general implementation is as follows - In project/src/main we implement the core of the emulator. This includes a basic reimplementation of some of CC's classes to work on the web (mostly the HTTP API and ComputerThread), and some additional code to expose the computers to Javascript. - This is all then compiled to Javascript using [TeaVM][1] (we actually use a [personal fork of it][2] as there's a couple of changes I've not upstreamed yet). - The Javascript side then pulls in the these compiled classes (and the CC ROM) and hooks them up to [cc-web-term][3] to display the actual computer. - As we're no longer pulling in copy-cat, we can simplify our bundling system a little - we now just compile to ESM modules directly. [1]: https://github.com/konsoletyper/teavm [2]: https://github.com/SquidDev/teavm/tree/squid-patches [3]: https://github.com/squiddev-cc/cc-web-term
2023-10-03 08:19:19 +00:00
annotations = ["jsr305", "checkerFramework", "jetbrainsAnnotations"]
Fix several off-by-one issues in UploadFileMessage We now fuzz UploadFileMessage, generating random files and checking they round-trip correctly. The joy of having a long-lasting refactor branch with an absolutely massive diff, is that you end up spotting bugs, and then it's a massive pain to merge the fix back into trunk!
2022-10-21 22:10:18 +00:00
kotlin = ["kotlin-stdlib", "kotlin-coroutines"]
Improve packaging of published jars - Publish javadoc again: for now this is just the common-api - Remove all dependencies from the published Forge jar. This is technically not needed (fg.deobf does this anyway), but seems sensible.
2022-11-08 16:43:27 +00:00
# Minecraft
Replace Forge Config port with a NYI version While it is a really nice library, it ends up being a bit overkill for our needs - we don't need config syncing or anything. By NIHing our own, we can drop one dependency and ease the updating burden a little. Closes #1296
2023-03-14 22:47:34 +00:00
externalMods-common = ["jei-api", "nightConfig-core", "nightConfig-toml"]
Add back MoreRed support I removed this in aa0d544bbac13dfff6736634c6ef9ac72f0d6cbe, way back in late 2021. Looks like it's been updating in the meantime and I hadn't noticed, so add it back. I've simplified the code a little bit, to make use of our new capability helpers, but otherwise it's almost exactly the same :D.
2023-08-27 23:04:46 +00:00
externalMods-forge-compile = ["moreRed", "oculus", "jei-api"]
Update to 1.20.4
2024-01-31 20:55:14 +00:00
externalMods-forge-runtime = []
Use permission APIs for the /computercraft command - Add a generic PermissionRegistry interface. This behaves similarly to our ShaderMod interface, searching all providers until it finds a compatible one. We could just make this part of the platform code instead, but this allows us to support multiple systems on Fabric, where things are less standardised. This interface behaves like a registry, rather than a straight `getPermission(node, player)` method, as Forge requires us to list our nodes up-front. - Add Forge (using the built-in system) and Fabric (using fabric-permissions-api) implementations of the above interface. - Register permission nodes for our commands, and use those instead. This does mean that the permissions check for the root /computercraft command now requires enumerating all child commands (and so potential does 7 permission lookups), but hopefully this isn't too bad in practice. - Remove UserLevel.OWNER - we never used this anywhere, and I can't imagine we'll want to in the future.
2023-08-27 11:15:55 +00:00
externalMods-fabric-compile = ["fabricPermissions", "iris", "jei-api", "rei-api", "rei-builtin"]
Update to 1.20.4
2024-01-31 20:55:14 +00:00
externalMods-fabric-runtime = []
Improve packaging of published jars - Publish javadoc again: for now this is just the common-api - Remove all dependencies from the published Forge jar. This is technically not needed (fg.deobf does this anyway), but seems sensible.
2022-11-08 16:43:27 +00:00
Fix several off-by-one issues in UploadFileMessage We now fuzz UploadFileMessage, generating random files and checking they round-trip correctly. The joy of having a long-lasting refactor branch with an absolutely massive diff, is that you end up spotting bugs, and then it's a massive pain to merge the fix back into trunk!
2022-10-21 22:10:18 +00:00
# Testing
test = ["junit-jupiter-api", "junit-jupiter-params", "hamcrest", "jqwik-api"]
testRuntime = ["junit-jupiter-engine", "jqwik-engine"]
Build a web-based emulator for the documentation site (#1597) Historically we've used copy-cat to provide a web-based emulator for running example code on our documentation site. However, copy-cat is often out-of-date with CC:T, which means example snippets fail when you try to run them! This commit vendors in copy-cat (or rather an updated version of it) into CC:T itself, allowing us to ensure the emulator is always in sync with the mod. While the ARCHITECTURE.md documentation goes into a little bit more detail here, the general implementation is as follows - In project/src/main we implement the core of the emulator. This includes a basic reimplementation of some of CC's classes to work on the web (mostly the HTTP API and ComputerThread), and some additional code to expose the computers to Javascript. - This is all then compiled to Javascript using [TeaVM][1] (we actually use a [personal fork of it][2] as there's a couple of changes I've not upstreamed yet). - The Javascript side then pulls in the these compiled classes (and the CC ROM) and hooks them up to [cc-web-term][3] to display the actual computer. - As we're no longer pulling in copy-cat, we can simplify our bundling system a little - we now just compile to ESM modules directly. [1]: https://github.com/konsoletyper/teavm [2]: https://github.com/SquidDev/teavm/tree/squid-patches [3]: https://github.com/squiddev-cc/cc-web-term
2023-10-03 08:19:19 +00:00
# Build tools
Improve our version tooling - Add a check to ensure declared dependencies in the :core project, and those inherited from Minecraft are the same. - Compute the next Cobalt version, rather than specifying it manually. - Add the gradle versions plugin (and version catalog update), and update some versions.
2023-12-19 18:12:21 +00:00
teavm-api = ["teavm-jso", "teavm-jso-apis", "teavm-platform", "teavm-classlib", "teavm-metaprogramming-api"]
teavm-tooling = ["teavm-tooling", "teavm-metaprogramming-impl", "teavm-jso-impl"]
Reference in New Issue Copy Permalink