1
0
mirror of https://github.com/SquidDev-CC/CC-Tweaked synced 2024-12-14 20:20:30 +00:00
Commit Graph

7 Commits

Author SHA1 Message Date
Jonathan Coates
76710eec9d
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
Jonathan Coates
c8c128d335
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
Jonathan Coates
71f81e1201
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
Jonathan Coates
6ab90dc30d
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
Jonathan Coates
0cfdd7b5e9
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
Jonathan Coates
af5d816798
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 18:19:51 +01:00
Jonathan Coates
ba64e06ca7
Use a Gradle plugin to download illuaminate
Previously illumainate required manual users to manually download it and
place it in ./bin/. This is both inconvenient for the user, and makes it
hard to ensure people are running the "right" version.

We now provide a small Gradle plugin which registers illuaminate as a
ependency, downloading the appropriate (now versioned!) file. This also
theoretically supports Macs, though I don't have access to one to test
this.

This enables the following changes:

 - The Lua lint script has been converted to a Gradle task (./gradle
   lintLua).

 - illuaminateDocs now uses a task definition with an explicit output
   directory. We can now consume this output as an input to another
   task, and get a task dependency implicitly.

 - Move the pre-commit config into the root of the tree. We can now use
   the default GitHub action to run our hooks.

 - Simplify CONTRIBUTING.md a little bit. Hopefully it's less
   intimidating now.
2022-09-11 14:11:33 +01:00