mirrors/CC-Tweaked
1
0
Fork 0
mirror of https://github.com/SquidDev-CC/CC-Tweaked synced 2025-02-22 22:10:09 +00:00
Code Issues Releases Wiki Activity
CC-Tweaked/gradle/libs.versions.toml

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

200 lines
10 KiB
TOML
Raw Permalink 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 23:10:18 +01: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 21:09:08 +01:00
# Minecraft
# MC version is specified in gradle.properties, as we need that in settings.gradle.
Actually update NeoForge to 1.20.5 NF now loads mods from neoforge.mods.toml rather than mods.toml, so CC wasn't actually being loaded. Tests all passed, because they didn't get run in the first place!
2024-04-26 17:57:20 +01:00
# Remember to update corresponding versions in fabric.mod.json/neoforge.mods.toml
Update to Minecraft 1.21.1 I'm not sure we *need* to do this (the two versions are compatible), but probably a good idea anyway.
2024-08-14 18:38:07 +01:00
fabric-api = "0.102.1+1.21.1"
Update to Minecraft 1.21 API Changes: - Minecraft had updated ModelResourceLocation to no longer inherit from ResourceLocation. To allow referencing both already baked models (ModelResourceLocation) and loading new models (via ResourceLocation) in turtle model loadders, we add a new "ModelLocation" class, that acts as a union between the two. I'm not entirely convinced by the design here, so might end up changing again before a stable release.o - Merge IMedia.getAudioTitle and IMedia.getAudio into a single IMedia.getAudio method, which now returns a JukeboxSong rather than a SoundEvent. Other update notes: - Minecraft had rewritten how buffers are managed again. This is a fairly minor change for us (vertex -> addVertex, normal -> setNormal, etc...), with the exception that you can no longer use MultiBufferSource.immediate with the tesselator. I've replaced this with GuiGraphics.bufferSource, which appears to be fine, but worth keeping an eye on in case there's any odd render state issues. - Crafting now uses a CraftingInput (a list of items) rather than a CraftingContainer, which allows us to simplify turtle crafting code.
2024-06-22 16:19:59 +01:00
fabric-loader = "0.15.11"
Update to Minecraft 1.21.1 I'm not sure we *need* to do this (the two versions are compatible), but probably a good idea anyway.
2024-08-14 18:38:07 +01:00
neoForge = "21.1.9"
Update to 1.20.4
2024-01-31 20:55:14 +00:00
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"
Udpate to latest Neo, Fabric and Parchment - Update to latest NeoForge, fixing issues with config API changes. Closes #1903. - Update to latest Fabric, switching to the ender pearl conventional tag, and new loot API.
2024-07-28 16:47:41 +01:00
parchment = "2024.07.28"
parchmentMc = "1.21"
Update to Minecraft 1.21.1 I'm not sure we *need* to do this (the two versions are compatible), but probably a good idea anyway.
2024-08-14 18:38:07 +01:00
yarn = "1.21.1+build.1"
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 21:09:08 +01: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"
Update to 1.20.5 (#1793) - Switch most network code to use StreamCodec - Turtle/pocket computer upgrades now use DataComponentPatch instead of raw NBT.
2024-04-25 21:32:48 +01:00
slf4j = "2.0.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
# Core dependencies (independent of Minecraft)
asm = "9.6"
autoService = "1.1.1"
checkerFramework = "3.42.0"
Update Cobalt to 0.9.5 - Fix several issues with large doubles - Fix metatable cache not being cleared
2024-11-12 21:11:22 +00:00
cobalt = { strictly = "0.9.5" }
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 09:30:29 +01:00
jzlib = "1.1.3"
A few more gametests, update to Gradle 8.12 Okay, listen. I started writing a few more gametests (see #1682), and then thought I'd do a cheeky Gradle update. However, that broke vanilla-extract[^1], and also triggered a load of deprecation warnings, and at that point it was too late to separate the too. [^1]: https://github.com/cc-tweaked/vanilla-extract/commit/8975ed5a7bd739df15d24f6e93ebeef4e88cc367
2025-01-12 18:26:51 +00:00
kotlin = "2.1.0"
kotlin-coroutines = "1.10.1"
nightConfig = "3.8.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 23:10:18 +01: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 Minecraft 1.21 API Changes: - Minecraft had updated ModelResourceLocation to no longer inherit from ResourceLocation. To allow referencing both already baked models (ModelResourceLocation) and loading new models (via ResourceLocation) in turtle model loadders, we add a new "ModelLocation" class, that acts as a union between the two. I'm not entirely convinced by the design here, so might end up changing again before a stable release.o - Merge IMedia.getAudioTitle and IMedia.getAudio into a single IMedia.getAudio method, which now returns a JukeboxSong rather than a SoundEvent. Other update notes: - Minecraft had rewritten how buffers are managed again. This is a fairly minor change for us (vertex -> addVertex, normal -> setNormal, etc...), with the exception that you can no longer use MultiBufferSource.immediate with the tesselator. I've replaced this with GuiGraphics.bufferSource, which appears to be fine, but worth keeping an eye on in case there's any odd render state issues. - Crafting now uses a CraftingInput (a list of items) rather than a CraftingContainer, which allows us to simplify turtle crafting code.
2024-06-22 16:19:59 +01:00
emi = "1.1.7+1.21"
Update to MC 1.20.6 - Update EMI and REI integration, and fix some issues with the upgrade crafting hooks. - Just use smooth stone for recipes, not #c:stone. We're mirroring redstone's crafting recipes here. - Some cleanup to printouts. - Remote upgrade data generators - these can be replaced with the standard registry data generators. - Remove the API's PlatformHelper - we no longer have any platform-specific code in the API.
2024-05-07 22:58:25 +01:00
fabricPermissions = "0.3.1"
Unify Iris integrations Iris now has built-in support for NeoForge, so we can use the same integration on both. We also re-enable Forge's client tests, and test Iris there too. Fixes #1967
2024-09-11 20:07:12 +01:00
iris-fabric = "1.8.0-beta.3+1.21-fabric"
iris-forge = "1.8.0-beta.3+1.21-neoforge"
Update JEI to fix crash with NF
2024-08-19 18:28:59 +01:00
jei = "19.8.2.99"
Update to Minecraft 1.21 API Changes: - Minecraft had updated ModelResourceLocation to no longer inherit from ResourceLocation. To allow referencing both already baked models (ModelResourceLocation) and loading new models (via ResourceLocation) in turtle model loadders, we add a new "ModelLocation" class, that acts as a union between the two. I'm not entirely convinced by the design here, so might end up changing again before a stable release.o - Merge IMedia.getAudioTitle and IMedia.getAudio into a single IMedia.getAudio method, which now returns a JukeboxSong rather than a SoundEvent. Other update notes: - Minecraft had rewritten how buffers are managed again. This is a fairly minor change for us (vertex -> addVertex, normal -> setNormal, etc...), with the exception that you can no longer use MultiBufferSource.immediate with the tesselator. I've replaced this with GuiGraphics.bufferSource, which appears to be fine, but worth keeping an eye on in case there's any odd render state issues. - Crafting now uses a CraftingInput (a list of items) rather than a CraftingContainer, which allows us to simplify turtle crafting code.
2024-06-22 16:19:59 +01:00
modmenu = "11.0.0-rc.4"
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-28 00:04:46 +01:00
moreRed = "4.0.0.4"
Update to Minecraft 1.21 API Changes: - Minecraft had updated ModelResourceLocation to no longer inherit from ResourceLocation. To allow referencing both already baked models (ModelResourceLocation) and loading new models (via ResourceLocation) in turtle model loadders, we add a new "ModelLocation" class, that acts as a union between the two. I'm not entirely convinced by the design here, so might end up changing again before a stable release.o - Merge IMedia.getAudioTitle and IMedia.getAudio into a single IMedia.getAudio method, which now returns a JukeboxSong rather than a SoundEvent. Other update notes: - Minecraft had rewritten how buffers are managed again. This is a fairly minor change for us (vertex -> addVertex, normal -> setNormal, etc...), with the exception that you can no longer use MultiBufferSource.immediate with the tesselator. I've replaced this with GuiGraphics.bufferSource, which appears to be fine, but worth keeping an eye on in case there's any odd render state issues. - Crafting now uses a CraftingInput (a list of items) rather than a CraftingContainer, which allows us to simplify turtle crafting code.
2024-06-22 16:19:59 +01:00
rei = "16.0.729"
Unify Iris integrations Iris now has built-in support for NeoForge, so we can use the same integration on both. We also re-enable Forge's client tests, and test Iris there too. Fixes #1967
2024-09-11 20:07:12 +01:00
sodium-fabric = "mc1.21-0.6.0-beta.1-fabric"
sodium-forge = "mc1.21-0.6.0-beta.1-neoforge"
Update to 1.20.5 (#1793) - Switch most network code to use StreamCodec - Turtle/pocket computer upgrades now use DataComponentPatch instead of raw NBT.
2024-04-25 21:32:48 +01:00
mixinExtra = "0.3.5"
Register modems as attached to their adjacent block In c8eadf401190db2b9c3145f768063097b9c345bd we marked our various modems as "brittle", which ensures they do not pop-off computers when the whole structure moves. However, this still requires the modem to be glued — if the modem is outside the superglue range, it will still pop off. We can fix it by registering a special "attached check" for the various modem blocks, which says that the modem should be moved when the adjacent block does. Fixes #1913
2024-07-26 18:28:13 +01:00
create-forge = "0.5.1.f-33"
create-fabric = "0.5.1-f-build.1467+mc1.20.1"
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 23:10:18 +01: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"
More Gradle cleanup Mostly configuration cache support. And an aborted attempt at updating spotless, which just resulted in a bunch of ktlint issues :/.
2025-01-13 21:54:20 +00:00
junit = "5.11.4"
junitPlatform = "1.11.4"
Clean up the wired network tests - Replace usages of WiredNetwork.connect/disconnect/remove with the WiredNode equivalents. - Convert "testLarge" into a proper JMH benchmark. - Don't put a peripheral on every node in the benchmarks. This isn't entirely representative, and means the peripheral juggling code ends up dominating the benchmark time.
2024-02-24 14:52:44 +00:00
jmh = "1.37"
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 23:10:18 +01: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 17:47:39 +01:00
# Build tools
Add redstone relay block (#2002) - Move redstone methods out of the IAPIEnvironment, and into a new RedstoneAccess. We similarly move the implementation from Environment into a new RedstoneState class. The interface is possibly a little redundant (interfaces with a single implementation are always a little suspect), but it's nice to keep the consumer/producer interfaces separate. - Abstract most redstone API methods into a separate shared class, that can be used by both the rs API and the new redstone relay. - Add the new redstone relay block. The docs are probably a little lacking here, but I really struggled to write anything which wasn't just "look, it's the same as the redstone API".
2024-11-12 09:05:27 +00:00
cctJavadoc = "1.8.3"
Merge branch 'mc-1.20.x' into mc-1.21.x
2024-11-15 09:25:10 +00:00
checkstyle = "10.20.1"
Update ErrorProne
2024-04-28 18:32:19 +01:00
errorProne-core = "2.27.0"
Generic dependency update A couple of changes caused by checkstyle being a little more strict.
2023-08-31 19:14:37 +01:00
errorProne-plugin = "3.1.0"
A few more gametests, update to Gradle 8.12 Okay, listen. I started writing a few more gametests (see #1682), and then thought I'd do a cheeky Gradle update. However, that broke vanilla-extract[^1], and also triggered a load of deprecation warnings, and at that point it was too late to separate the too. [^1]: https://github.com/cc-tweaked/vanilla-extract/commit/8975ed5a7bd739df15d24f6e93ebeef4e88cc367
2025-01-12 18:26:51 +00:00
fabric-loom = "1.9.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
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 19:14:37 +01:00
ideaExt = "1.1.7"
Update npm packages and illuaminate
2024-10-27 10:01:29 +00:00
illuaminate = "0.1.0-74-gf1551d5"
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"
Clean up Javadocs a little I've no motivation for modding right now, but always got time for build system busywork! CC:T (and CC before that) has always published its API docs. However, they're not always the most helpful — they're useful if you know what you're looking for, but aren't a good getting-started guide. Part of the issue here is there's no examples, and everything is described pretty abstractly. I have occasionally tried to improve this (e.g. the peripheral docs in bdffabc08e2eb9895f966c949acc8334a2bf4475), but it's a long road. This commit adds a new example mod, which registers peripherals, an API and a turtle upgrade. While the mod itself isn't exported as part of the docs, we reference blocks of it using Java's new {@snippet} tag. - Switch the Forge project to use NeoForge's new Legacy MDG plugin. We don't *need* to do this, but it means the build logic for Forge and NeoForge is more closely aligned. - Add a new SnippetTaglet, which is a partial backport of Java 18+'s {@snippet}. - Add an example mod. This is a working multi-loader mod, complete with datagen (albeit with no good multi-loader abstractions). - Move our existing <pre>{@code ...}</pre> blocks into the example mod, replacing them with {@snippet}s. - Add a new overview page to the docs, providing some getting-started information. We had this already in the dan200.computercraft.api package docs, but it's not especially visible there.
2025-01-09 20:47:51 +00:00
modDevGradle = "2.0.74"
Update to latest NullAway This fixes several issues with @Nullable fields not being checked. This is great in principle, but a little annoying in practice as MC's @Nullable annotations are sometimes a little overly strict -- we now need to wrap a couple of things in assertNonNull checks.
2024-04-06 08:38:44 +01:00
nullAway = "0.10.25"
Shadow netty rather than jar-in-jaring Under Forge, netty-codec lives on the BOOT layer. However, this means it does not have access to our jzlib (which lives on the GAME layer). To fix this, we now shadow netty-codec (and its dependents, like netty-http and netty-proxy) rather than jar-in-jaring them. This involves some horrible build logic, but means websocket compression works on Forge. Fixes #1958.
2024-09-11 18:00:11 +01:00
shadow = "8.3.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
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"
Small bits of cleanup Build system: - Switch to our new maven server. This has a cleaner separation between published packages and mirrored packages, to avoid leaking those into other people's builds. - Update Gradle and Loom versions. Code: - Link to definitions instead in the breaking changes page. - Fix several unused variable warnings. Other: - Remove unsupported Minecraft versions from the issue template.
2024-06-26 18:07:56 +01:00
teavm = "0.11.0-SQUID.1"
A few more gametests, update to Gradle 8.12 Okay, listen. I started writing a few more gametests (see #1682), and then thought I'd do a cheeky Gradle update. However, that broke vanilla-extract[^1], and also triggered a load of deprecation warnings, and at that point it was too late to separate the too. [^1]: https://github.com/cc-tweaked/vanilla-extract/commit/8975ed5a7bd739df15d24f6e93ebeef4e88cc367
2025-01-12 18:26:51 +00:00
vanillaExtract = "0.2.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
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 17:47:39 +01: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 23:10:18 +01: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 09:19:19 +01: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 23:10:18 +01: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 17:55:56 +01: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 23:50:44 +01: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 09:30:29 +01: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 23:10:18 +01: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 09:30:29 +01: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" }
Shadow netty rather than jar-in-jaring Under Forge, netty-codec lives on the BOOT layer. However, this means it does not have access to our jzlib (which lives on the GAME layer). To fix this, we now shadow netty-codec (and its dependents, like netty-http and netty-proxy) rather than jar-in-jaring them. This involves some horrible build logic, but means websocket compression works on Forge. Fixes #1958.
2024-09-11 18:00:11 +01:00
netty-codec = { module = "io.netty:netty-codec", version.ref = "netty" }
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 19:58:24 +01:00
netty-proxy = { module = "io.netty:netty-handler-proxy", version.ref = "netty" }
Shadow netty rather than jar-in-jaring Under Forge, netty-codec lives on the BOOT layer. However, this means it does not have access to our jzlib (which lives on the GAME layer). To fix this, we now shadow netty-codec (and its dependents, like netty-http and netty-proxy) rather than jar-in-jaring them. This involves some horrible build logic, but means websocket compression works on Forge. Fixes #1958.
2024-09-11 18:00:11 +01:00
netty-socks = { module = "io.netty:netty-codec-socks", 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 23:10:18 +01: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
Register modems as attached to their adjacent block In c8eadf401190db2b9c3145f768063097b9c345bd we marked our various modems as "brittle", which ensures they do not pop-off computers when the whole structure moves. However, this still requires the modem to be glued — if the modem is outside the superglue range, it will still pop off. We can fix it by registering a special "attached check" for the various modem blocks, which says that the modem should be moved when the adjacent block does. Fixes #1913
2024-07-26 18:28:13 +01:00
create-fabric = { module = "com.simibubi.create:create-fabric-1.20.1", version.ref = "create-fabric" }
create-forge = { module = "com.simibubi.create:create-1.20.1", version.ref = "create-forge" }
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
fabric-api = { module = "net.fabricmc.fabric-api:fabric-api", version.ref = "fabric-api" }
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 22:06:40 +01:00
fabric-junit = { module = "net.fabricmc:fabric-loader-junit", version.ref = "fabric-loader" }
Register modems as attached to their adjacent block In c8eadf401190db2b9c3145f768063097b9c345bd we marked our various modems as "brittle", which ensures they do not pop-off computers when the whole structure moves. However, this still requires the modem to be glued — if the modem is outside the superglue range, it will still pop off. We can fix it by registering a special "attached check" for the various modem blocks, which says that the modem should be moved when the adjacent block does. Fixes #1913
2024-07-26 18:28:13 +01:00
fabric-loader = { module = "net.fabricmc:fabric-loader", 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 12:15:55 +01:00
fabricPermissions = { module = "me.lucko:fabric-permissions-api", version.ref = "fabricPermissions" }
Unify Iris integrations Iris now has built-in support for NeoForge, so we can use the same integration on both. We also re-enable Forge's client tests, and test Iris there too. Fixes #1967
2024-09-11 20:07:12 +01:00
iris-fabric = { module = "maven.modrinth:iris", version.ref = "iris-fabric" }
iris-forge = { module = "maven.modrinth:iris", version.ref = "iris-forge" }
Update to Minecraft 1.21 API Changes: - Minecraft had updated ModelResourceLocation to no longer inherit from ResourceLocation. To allow referencing both already baked models (ModelResourceLocation) and loading new models (via ResourceLocation) in turtle model loadders, we add a new "ModelLocation" class, that acts as a union between the two. I'm not entirely convinced by the design here, so might end up changing again before a stable release.o - Merge IMedia.getAudioTitle and IMedia.getAudio into a single IMedia.getAudio method, which now returns a JukeboxSong rather than a SoundEvent. Other update notes: - Minecraft had rewritten how buffers are managed again. This is a fairly minor change for us (vertex -> addVertex, normal -> setNormal, etc...), with the exception that you can no longer use MultiBufferSource.immediate with the tesselator. I've replaced this with GuiGraphics.bufferSource, which appears to be fine, but worth keeping an eye on in case there's any odd render state issues. - Crafting now uses a CraftingInput (a list of items) rather than a CraftingContainer, which allows us to simplify turtle crafting code.
2024-06-22 16:19:59 +01:00
jei-api = { module = "mezz.jei:jei-1.21-common-api", version.ref = "jei" }
jei-fabric = { module = "mezz.jei:jei-1.21-fabric", version.ref = "jei" }
jei-forge = { module = "mezz.jei:jei-1.21-neoforge", 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" }
Update to 1.20.5 (#1793) - Switch most network code to use StreamCodec - Turtle/pocket computer upgrades now use DataComponentPatch instead of raw NBT.
2024-04-25 21:32:48 +01:00
mixinExtra = { module = "io.github.llamalad7:mixinextras-common", version.ref = "mixinExtra" }
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-28 00:04:46 +01:00
moreRed = { module = "commoble.morered:morered-1.20.1", version.ref = "moreRed" }
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" }
Unify Iris integrations Iris now has built-in support for NeoForge, so we can use the same integration on both. We also re-enable Forge's client tests, and test Iris there too. Fixes #1967
2024-09-11 20:07:12 +01:00
sodium-fabric = { module = "maven.modrinth:sodium", version.ref = "sodium.fabric" }
sodium-forge = { module = "maven.modrinth:sodium", version.ref = "sodium.forge" }
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 23:10:18 +01: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" }
More Gradle cleanup Mostly configuration cache support. And an aborted attempt at updating spotless, which just resulted in a bunch of ktlint issues :/.
2025-01-13 21:54:20 +00:00
junit-platform-launcher = { module = "org.junit.platform:junit-platform-launcher", version.ref = "junitPlatform" }
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" }
Clean up the wired network tests - Replace usages of WiredNetwork.connect/disconnect/remove with the WiredNode equivalents. - Convert "testLarge" into a proper JMH benchmark. - Don't put a peripheral on every node in the benchmarks. This isn't entirely representative, and means the peripheral juggling code ends up dominating the benchmark time.
2024-02-24 14:52:44 +00:00
jmh = { module = "org.openjdk.jmh:jmh-core", version.ref = "jmh" }
jmh-processor = { module = "org.openjdk.jmh:jmh-generator-annprocess", version.ref = "jmh" }
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 23:10:18 +01: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 17:55:56 +01: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 20:47:47 +01: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 21:09:08 +01: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 20:47:47 +01:00
checkstyle = { module = "com.puppycrawl.tools:checkstyle", version.ref = "checkstyle" }
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 22:06:40 +01: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 18:17:02 +01: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" }
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" }
Clean up Javadocs a little I've no motivation for modding right now, but always got time for build system busywork! CC:T (and CC before that) has always published its API docs. However, they're not always the most helpful — they're useful if you know what you're looking for, but aren't a good getting-started guide. Part of the issue here is there's no examples, and everything is described pretty abstractly. I have occasionally tried to improve this (e.g. the peripheral docs in bdffabc08e2eb9895f966c949acc8334a2bf4475), but it's a long road. This commit adds a new example mod, which registers peripherals, an API and a turtle upgrade. While the mod itself isn't exported as part of the docs, we reference blocks of it using Java's new {@snippet} tag. - Switch the Forge project to use NeoForge's new Legacy MDG plugin. We don't *need* to do this, but it means the build logic for Forge and NeoForge is more closely aligned. - Add a new SnippetTaglet, which is a partial backport of Java 18+'s {@snippet}. - Add an example mod. This is a working multi-loader mod, complete with datagen (albeit with no good multi-loader abstractions). - Move our existing <pre>{@code ...}</pre> blocks into the example mod, replacing them with {@snippet}s. - Add a new overview page to the docs, providing some getting-started information. We had this already in the dan200.computercraft.api package docs, but it's not especially visible there.
2025-01-09 20:47:51 +00:00
modDevGradle = { module = "net.neoforged:moddev-gradle", version.ref = "modDevGradle" }
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 17:47:39 +01: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 09:19:19 +01:00
teavm-classlib = { module = "org.teavm:teavm-classlib", version.ref = "teavm" }
Update to latest TeaVM - Add the core TeaVM jar to the runtime the classpath, to ensure various runtime classes are present. - Fix computer initialisation errors not being displayed on the screen. The terminal was set to the default 0x0 size when logging the error, and so never displayed anything!
2024-04-17 21:57:11 +01:00
teavm-core = { module = "org.teavm:teavm-core", version.ref = "teavm" }
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 09:19:19 +01:00
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 17:47:39 +01: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 21:09:08 +01: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" }
Shadow netty rather than jar-in-jaring Under Forge, netty-codec lives on the BOOT layer. However, this means it does not have access to our jzlib (which lives on the GAME layer). To fix this, we now shadow netty-codec (and its dependents, like netty-http and netty-proxy) rather than jar-in-jaring them. This involves some horrible build logic, but means websocket compression works on Forge. Fixes #1958.
2024-09-11 18:00:11 +01:00
shadow = { id = "com.gradleup.shadow", version.ref = "shadow" }
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
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 21:09:08 +01: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 23:10:18 +01: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 09:19:19 +01: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 23:10:18 +01: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
Unify Iris integrations Iris now has built-in support for NeoForge, so we can use the same integration on both. We also re-enable Forge's client tests, and test Iris there too. Fixes #1967
2024-09-11 20:07:12 +01:00
externalMods-common = ["iris-forge", "jei-api", "nightConfig-core", "nightConfig-toml"]
externalMods-forge-compile = ["moreRed", "iris-forge", "jei-api"]
Update to Minecraft 1.21 API Changes: - Minecraft had updated ModelResourceLocation to no longer inherit from ResourceLocation. To allow referencing both already baked models (ModelResourceLocation) and loading new models (via ResourceLocation) in turtle model loadders, we add a new "ModelLocation" class, that acts as a union between the two. I'm not entirely convinced by the design here, so might end up changing again before a stable release.o - Merge IMedia.getAudioTitle and IMedia.getAudio into a single IMedia.getAudio method, which now returns a JukeboxSong rather than a SoundEvent. Other update notes: - Minecraft had rewritten how buffers are managed again. This is a fairly minor change for us (vertex -> addVertex, normal -> setNormal, etc...), with the exception that you can no longer use MultiBufferSource.immediate with the tesselator. I've replaced this with GuiGraphics.bufferSource, which appears to be fine, but worth keeping an eye on in case there's any odd render state issues. - Crafting now uses a CraftingInput (a list of items) rather than a CraftingContainer, which allows us to simplify turtle crafting code.
2024-06-22 16:19:59 +01:00
externalMods-forge-runtime = ["jei-forge"]
Unify Iris integrations Iris now has built-in support for NeoForge, so we can use the same integration on both. We also re-enable Forge's client tests, and test Iris there too. Fixes #1967
2024-09-11 20:07:12 +01:00
externalMods-fabric-compile = ["fabricPermissions", "iris-fabric", "jei-api", "rei-api", "rei-builtin"]
Update to Minecraft 1.21 API Changes: - Minecraft had updated ModelResourceLocation to no longer inherit from ResourceLocation. To allow referencing both already baked models (ModelResourceLocation) and loading new models (via ResourceLocation) in turtle model loadders, we add a new "ModelLocation" class, that acts as a union between the two. I'm not entirely convinced by the design here, so might end up changing again before a stable release.o - Merge IMedia.getAudioTitle and IMedia.getAudio into a single IMedia.getAudio method, which now returns a JukeboxSong rather than a SoundEvent. Other update notes: - Minecraft had rewritten how buffers are managed again. This is a fairly minor change for us (vertex -> addVertex, normal -> setNormal, etc...), with the exception that you can no longer use MultiBufferSource.immediate with the tesselator. I've replaced this with GuiGraphics.bufferSource, which appears to be fine, but worth keeping an eye on in case there's any odd render state issues. - Crafting now uses a CraftingInput (a list of items) rather than a CraftingContainer, which allows us to simplify turtle crafting code.
2024-06-22 16:19:59 +01:00
externalMods-fabric-runtime = ["jei-fabric", "modmenu"]
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 23:10:18 +01:00
# Testing
test = ["junit-jupiter-api", "junit-jupiter-params", "hamcrest", "jqwik-api"]
More Gradle cleanup Mostly configuration cache support. And an aborted attempt at updating spotless, which just resulted in a bunch of ktlint issues :/.
2025-01-13 21:54:20 +00:00
testRuntime = ["junit-jupiter-engine", "junit-platform-launcher", "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 09:19:19 +01: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