mirrors/CC-Tweaked
1
0
Fork 0
mirror of https://github.com/SquidDev-CC/CC-Tweaked synced 2024-12-15 04:30:29 +00:00
Code Issues Releases Wiki Activity
18fbd96c10
CC-Tweaked/gradle/libs.versions.toml

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

155 lines
7.3 KiB
TOML
Raw Normal View History

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.
Update to Minecraft 1.19.3 Lots of minor changes, but nothing too nasty - just tedious. Known bugs/issues: - REI and JEI haven't been updated at the time of writing, so our usage of their APIs may be incompatible. - Crash when opening the config UI in Fabric, as forgeconfigapi-port hasn't been updated yet. Will hold off on doing a release until those mods have updated.
2022-12-08 19:45:02 +00:00
fabric-api = "0.68.1+1.19.3"
fabric-loader = "0.14.11"
forge = "44.0.0"
Add a couple of errorprone plugins - Check that common code does not reference client-only classes. - Check that @ForgeOverride really overrides a method in Forge projects.
2022-11-10 00:03:09 +00:00
forgeSpi = "6.0.0"
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 Minecraft 1.19.3 Lots of minor changes, but nothing too nasty - just tedious. Known bugs/issues: - REI and JEI haven't been updated at the time of writing, so our usage of their APIs may be incompatible. - Crash when opening the config UI in Fabric, as forgeconfigapi-port hasn't been updated yet. Will hold off on doing a release until those mods have updated.
2022-12-08 19:45:02 +00:00
parchment = "2022.11.27"
Merge branch 'mc-1.18.x' into mc-1.19.x
2022-10-26 08:49:51 +00:00
parchmentMc = "1.19.2"
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 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 = "9.3"
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 = "1.0.1"
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 = "3.12.0"
Rewrite how we do inventory transfers - Add a new ContainerTransfer class to handle moving items between containers. This is now used for turtle.drop/turtle.suck as well as inventory methods. - Any other usages of IItemHandler (which are mostly on turtle inventories) now use Container and a couple of helper methods.
2022-11-08 21:31:17 +00:00
cobalt = "0.5.8"
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 = "8.5.6"
guava = "31.0.1-jre"
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 = "23.0.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"
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 = "1.7.10"
kotlin-coroutines = "1.6.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
logback = "1.2.11"
Rewrite how we do inventory transfers - Add a new ContainerTransfer class to handle moving items between containers. This is now used for turtle.drop/turtle.suck as well as inventory methods. - Any other usages of IItemHandler (which are mostly on turtle inventories) now use Container and a couple of helper methods.
2022-11-08 21:31:17 +00:00
netty = "4.1.77.Final"
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
nightConfig = "3.6.5"
slf4j = "1.7.36"
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
Resolve a few TODOs - Update ForgeConfigAPI to the latest version, to fix the race condition. - Move WirelessNetwork lifecycle management to ServerContext. - Some doc fixes.
2022-12-03 15:55:48 +00:00
forgeConfig = "4.2.7"
Update to Minecraft 1.19.3 Lots of minor changes, but nothing too nasty - just tedious. Known bugs/issues: - REI and JEI haven't been updated at the time of writing, so our usage of their APIs may be incompatible. - Crash when opening the config UI in Fabric, as forgeconfigapi-port hasn't been updated yet. Will hold off on doing a release until those mods have updated.
2022-12-08 19:45:02 +00:00
iris = "1.19.3-v1.4.6"
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
jei = "11.3.0.262"
Update to Minecraft 1.19.3 Lots of minor changes, but nothing too nasty - just tedious. Known bugs/issues: - REI and JEI haven't been updated at the time of writing, so our usage of their APIs may be incompatible. - Crash when opening the config UI in Fabric, as forgeconfigapi-port hasn't been updated yet. Will hold off on doing a release until those mods have updated.
2022-12-08 19:45:02 +00:00
modmenu = "5.0.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
oculus = "1.2.5"
Actually update README with the new maven coordinates Also bump REI to 1.19.3
2022-12-09 18:05:35 +00:00
rei = "10.0.578"
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 to Minecraft 1.19.3 Lots of minor changes, but nothing too nasty - just tedious. Known bugs/issues: - REI and JEI haven't been updated at the time of writing, so our usage of their APIs may be incompatible. - Crash when opening the config UI in Fabric, as forgeconfigapi-port hasn't been updated yet. Will hold off on doing a release until those mods have updated.
2022-12-08 19:45:02 +00:00
sodium = "mc1.19.3-0.4.6"
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
Update to Minecraft 1.19.3 Lots of minor changes, but nothing too nasty - just tedious. Known bugs/issues: - REI and JEI haven't been updated at the time of writing, so our usage of their APIs may be incompatible. - Crash when opening the config UI in Fabric, as forgeconfigapi-port hasn't been updated yet. Will hold off on doing a release until those mods have updated.
2022-12-08 19:45:02 +00:00
byteBuddy = "1.12.19"
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
hamcrest = "2.2"
jqwik = "1.7.0"
junit = "5.9.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
# Build tools
Pass project root to cct-javadoc Fixes #1238
2022-12-02 22:00:00 +00:00
cctJavadoc = "1.5.3"
Merge branch 'mc-1.16.x' into mc-1.18.x I dare say there's going to be some bugs with this. I was as careful as I could be, but yikes it was nasty.
2022-10-25 21:36:21 +00:00
checkstyle = "10.3.4"
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
curseForgeGradle = "1.0.11"
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-core = "2.14.0"
errorProne-plugin = "2.0.2"
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 = "1.0-SNAPSHOT"
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
forgeGradle = "5.1.+"
githubRelease = "2.2.12"
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
ideaExt = "1.1.6"
Handle file transfers inside CraftOS (#1190) - Add a new file_transfer event. This has the signature "file_transfer", TransferredFiles. TransferredFiles has a single method getFiles(), which returns a list of all transferred files. - Add a new "import" program which waits for a file_transfer event and writes files to the current directory. - If a file_transfer event is not handled (i.e. its getFiles() method is not called) within 5 seconds on the client, we display a toast informing the user on how to upload a file.
2022-10-29 11:01:23 +00:00
illuaminate = "0.1.0-7-g2a5a89c"
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
librarian = "1.+"
minotaur = "2.+"
mixinGradle = "0.7.+"
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"
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
quiltflower = "1.7.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
shadow = "7.1.2"
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 = "6.8.0"
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
taskTree = "2.1.0"
Move our public API into separate modules This adds two new modules: common-api and forge-api, which contain the common and Forge-specific interfaces for CC's Minecraft-specific API. We add a new PlatformHelper interface, which abstracts over some of the loader-specific functionality, such as reading registries[^1] or calling Forge-specific methods. This interface is then implemented in the main mod, and loaded via ServiceLoaders. Some other notes on this: - We now split shared and client-specific source code into separate modules. This is to make it harder to reference client code on the server, thus crashing the game. Eventually we'll split the main mod up too into separate source sets - this is, of course, a much bigger problem! - There's currently some nastiness here due to wanting to preserve binary compatibility of the API. We'll hopefully be able to remove this when 1.19.3 releases. - In order to build a separate Forge-specific API jar, we compile the common sources twice: once for the common jar and once for the Forge jar. Getting this to play nicely with IDEs is a little tricky and so we provide a cct.inlineProject(...) helper to handle everything. [^1]: We /can/ do this with vanilla's APIs, but it gives a lot of deprecation warnings. It just ends up being nicer to abstract over it.
2022-11-06 15:07:13 +00:00
vanillaGradle = "0.2.1-SNAPSHOT"
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" }
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" }
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
cobalt = { module = "org.squiddev:Cobalt", version.ref = "cobalt" }
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" }
Add a couple of errorprone plugins - Check that common code does not reference client-only classes. - Check that @ForgeOverride really overrides a method in Forge projects.
2022-11-10 00:03:09 +00:00
forgeSpi = { module = "net.minecraftforge:forgespi", version.ref = "forgeSpi" }
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" }
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" }
kotlin-stdlib = { module = "org.jetbrains.kotlin:kotlin-stdlib-jdk8", 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" }
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" }
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
forgeConfig = { module = "net.minecraftforge:forgeconfigapiport-fabric", version.ref = "forgeConfig" }
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" }
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
jei-api = { module = "mezz.jei:jei-1.19.2-common-api", version.ref = "jei" }
jei-fabric = { module = "mezz.jei:jei-1.19.2-fabric", version.ref = "jei" }
jei-forge = { module = "mezz.jei:jei-1.19.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" }
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
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
byteBuddyAgent = { module ="net.bytebuddy:byte-buddy-agent", version.ref = "byteBuddy" }
Update to Minecraft 1.19.3 Lots of minor changes, but nothing too nasty - just tedious. Known bugs/issues: - REI and JEI haven't been updated at the time of writing, so our usage of their APIs may be incompatible. - Crash when opening the config UI in Fabric, as forgeconfigapi-port hasn't been updated yet. Will hold off on doing a release until those mods have updated.
2022-12-08 19:45:02 +00:00
byteBuddy = { module ="net.bytebuddy:byte-buddy", version.ref = "byteBuddy" }
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
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" }
Support renaming files directly without copying/deleting In classic squid tradition: 20% code, and 80% test logic. Closes #962. Alas, whoever reported this has deleted their account, so they can't even be happy about it :(.
2022-12-04 21:59:30 +00:00
logback = { module = "ch.qos.logback:logback-classic", version.ref = "logback" }
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
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" }
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" }
Move our public API into separate modules This adds two new modules: common-api and forge-api, which contain the common and Forge-specific interfaces for CC's Minecraft-specific API. We add a new PlatformHelper interface, which abstracts over some of the loader-specific functionality, such as reading registries[^1] or calling Forge-specific methods. This interface is then implemented in the main mod, and loaded via ServiceLoaders. Some other notes on this: - We now split shared and client-specific source code into separate modules. This is to make it harder to reference client code on the server, thus crashing the game. Eventually we'll split the main mod up too into separate source sets - this is, of course, a much bigger problem! - There's currently some nastiness here due to wanting to preserve binary compatibility of the API. We'll hopefully be able to remove this when 1.19.3 releases. - In order to build a separate Forge-specific API jar, we compile the common sources twice: once for the common jar and once for the Forge jar. Getting this to play nicely with IDEs is a little tricky and so we provide a cct.inlineProject(...) helper to handle everything. [^1]: We /can/ do this with vanilla's APIs, but it gives a lot of deprecation warnings. It just ends up being nicer to abstract over it.
2022-11-06 15:07:13 +00:00
forgeGradle = { module = "net.minecraftforge.gradle:ForgeGradle", version.ref = "forgeGradle" }
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" }
Move our public API into separate modules This adds two new modules: common-api and forge-api, which contain the common and Forge-specific interfaces for CC's Minecraft-specific API. We add a new PlatformHelper interface, which abstracts over some of the loader-specific functionality, such as reading registries[^1] or calling Forge-specific methods. This interface is then implemented in the main mod, and loaded via ServiceLoaders. Some other notes on this: - We now split shared and client-specific source code into separate modules. This is to make it harder to reference client code on the server, thus crashing the game. Eventually we'll split the main mod up too into separate source sets - this is, of course, a much bigger problem! - There's currently some nastiness here due to wanting to preserve binary compatibility of the API. We'll hopefully be able to remove this when 1.19.3 releases. - In order to build a separate Forge-specific API jar, we compile the common sources twice: once for the common jar and once for the Forge jar. Getting this to play nicely with IDEs is a little tricky and so we provide a cct.inlineProject(...) helper to handle everything. [^1]: We /can/ do this with vanilla's APIs, but it gives a lot of deprecation warnings. It just ends up being nicer to abstract over it.
2022-11-06 15:07:13 +00:00
librarian = { module = "org.parchmentmc:librarian", version.ref = "librarian" }
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" }
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
quiltflower = { module = "io.github.juuxel:loom-quiltflower", version.ref = "quiltflower" }
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" }
Move our public API into separate modules This adds two new modules: common-api and forge-api, which contain the common and Forge-specific interfaces for CC's Minecraft-specific API. We add a new PlatformHelper interface, which abstracts over some of the loader-specific functionality, such as reading registries[^1] or calling Forge-specific methods. This interface is then implemented in the main mod, and loaded via ServiceLoaders. Some other notes on this: - We now split shared and client-specific source code into separate modules. This is to make it harder to reference client code on the server, thus crashing the game. Eventually we'll split the main mod up too into separate source sets - this is, of course, a much bigger problem! - There's currently some nastiness here due to wanting to preserve binary compatibility of the API. We'll hopefully be able to remove this when 1.19.3 releases. - In order to build a separate Forge-specific API jar, we compile the common sources twice: once for the common jar and once for the Forge jar. Getting this to play nicely with IDEs is a little tricky and so we provide a cct.inlineProject(...) helper to handle everything. [^1]: We /can/ do this with vanilla's APIs, but it gives a lot of deprecation warnings. It just ends up being nicer to abstract over it.
2022-11-06 15:07:13 +00:00
vanillaGradle = { module = "org.spongepowered:vanillagradle", version.ref = "vanillaGradle" }
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]
curseForgeGradle = { id = "net.darkhax.curseforgegradle", version.ref = "curseForgeGradle" }
forgeGradle = { id = "net.minecraftforge.gradle", version.ref = "forgeGradle" }
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" }
ideaExt = { id = "org.jetbrains.gradle.plugin.idea-ext", version.ref = "ideaExt" }
kotlin = { id = "org.jetbrains.kotlin.jvm", version.ref = "kotlin" }
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
librarian = { id = "org.parchmentmc.librarian.forgegradle", version.ref = "librarian" }
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
minotaur = { id = "com.modrinth.minotaur", version.ref = "minotaur" }
mixinGradle = { id = "org.spongepowered.mixin", version.ref = "mixinGradle" }
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
shadow = { id = "com.github.johnrengelman.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" }
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]
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
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
externalMods-common = ["jei-api", "forgeConfig", "nightConfig-core", "nightConfig-toml"]
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
externalMods-forge-compile = ["oculus", "jei-api"]
Update to Minecraft 1.19.3 Lots of minor changes, but nothing too nasty - just tedious. Known bugs/issues: - REI and JEI haven't been updated at the time of writing, so our usage of their APIs may be incompatible. - Crash when opening the config UI in Fabric, as forgeconfigapi-port hasn't been updated yet. Will hold off on doing a release until those mods have updated.
2022-12-08 19:45:02 +00:00
externalMods-forge-runtime = []
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
externalMods-fabric = ["fabric-loader", "fabric-api", "forgeConfig", "nightConfig-core", "nightConfig-toml"]
externalMods-fabric-compile = ["iris", "jei-api", "rei-api", "rei-builtin"]
Update to Minecraft 1.19.3 Lots of minor changes, but nothing too nasty - just tedious. Known bugs/issues: - REI and JEI haven't been updated at the time of writing, so our usage of their APIs may be incompatible. - Crash when opening the config UI in Fabric, as forgeconfigapi-port hasn't been updated yet. Will hold off on doing a release until those mods have updated.
2022-12-08 19:45:02 +00:00
externalMods-fabric-runtime = ["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 22:10:18 +00:00
# Testing
test = ["junit-jupiter-api", "junit-jupiter-params", "hamcrest", "jqwik-api"]
testRuntime = ["junit-jupiter-engine", "jqwik-engine"]
Reference in New Issue Copy Permalink