Breaking changes:
- `FabricBrewingRecipeRegistry.registerPotionRecipe` takes `RegistryEntry<Potion>` instead of `Potion`
- `SculkSensorFrequencyRegistry.regster` takes `RegistryKey<GameEvent>` instead of `GameEvent`
- `FabricLanguageProvider.add` takes `RegistryEntry<EntityAttribute>` instead of `EntityAttribute`
- `FabricTagProvider.GameEventTagProvider` was removed replace with `FabricTagProvider<GameEvent>`
- `FabricItem.getAttributeModifiers` returns a Multimap with a key of `RegistryEntry<EntityAttribute>` instead of `EntityAttribute`
- `ModifyItemAttributeModifiersCallback.modifyAttributeModifiers` takes Multimap with a key of `RegistryEntry<EntityAttribute>` instead of `EntityAttribute`
* Update to loom 1.3
* Fix more 1.3 deprecations
* Opps
* Move to mod publish plugin
* Revert some changes
* Fix some more Gradle deprecations
* Fix names
* Remove extra stuff
* Cleanup
* Move duplicated v0/v1 impl packages to v0 subpackages
Fixes#2616. The convention is adopted from the command API (v1)
whose impl classes have the v1 subpackage.
* Separate client code into its own packages everywhere
* Fix code style
* Fix code style, part 2
* Allow v0 in package names
* Allow v0 in package names (fixed)
(cherry picked from commit 9244241639)
A common source of crashes on modded Minecraft servers comes from modders accidently calling client only code from the client, this PR is another large step towards elimitating that.
This PR has been months in the making and years in the planning, requiring major changes to Loom & Loader. In recent Minecraft versions Mojang has made it easier than ever to cleanly split the jar, going against the status-quo of merging the client and server into one jar.
From the start we have designed Fabric to have a very clear split between client and common (client & server) code. Fabric has always encoraged keeping client only code seprate from the server, this can be seen at a fundamental level with the entrypoints in Loader. Fabric API's have all been designed with this mind.
This PR provides a compile safety net around Fabric API using client only code on the server. Even though there are almost 400 changed files, minimal changes beyond moving the files were required to achieve this in Fabric API, thanks to the effort of all contributors in the past.
These changes should not affect modders or players in anyway, a single "universal" jar is still produced. Im happy to awnswer any questions.
* Move deprecated modules to a sub directory.
Remove deprecated modules from the default maven pom
Create a new "fabric-api-legacy" bom with the deprecated modules.
* Fix main "fabric" project not beign a dep for the legacy bom.
* rename artifact to fabric-api-deprecated
* Spotless
* Use the latest version of spotless.
