* 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)
* Update command registration API to reflect vanilla changes
* Allow module versions in impl+mixin packages
* Use v2 module, keeping v1 for server commands at least
* update, address review
Co-authored-by: modmuss50 <modmuss50@gmail.com>
# Fabric API Lookup API v1
## Introduction
This module allows Api instances to be associated with game objects without specifying how the association is implemented. This is useful when the same Api could be implemented more than once or implemented in different ways.
Many thanks to @Grondag for providing the original concept (#1072).
Thanks also go to @i509VCB, @Pyrofab, @sfPlayer1 and the others who were involved with the design of this module.
This is the foundation upon which can be built for example a fluid transfer api (#1166). Closes#1199.
## Flexible Api Querying
## Block Api Usage example
## Building blocks
This PR was changed a lot, please have a look at the README, the package info, and the javadoc for `BlockApiLookup` and `ApiLookupMap` for up-to-date documentation.
## More usage examples
FastTransferLib (https://github.com/Technici4n/FastTransferLib) is an experiment to build an item, fluid and energy transfer api on top of this module. (Which was until recently called `fabric-provider-api-v1`.)
## Missing things?
~~I could add an overload of `BlockApiLookup#find` with nullable `BlockState` and `BlockEntity` parameters, so that the caller can directly provide them if they are available for some reason.~~ Added in later commits.
There is no module to retrieve apis from items or entities yet because there were unsolved issues with those. The community can use the provided building blocks to experiment with their own implementations of `ItemStackApiLookup` and `EntityApiLookup` until the way forward becomes clear, but let's please not delay the `BlockApiLookup` because of that.
Co-authored-by: i509VCB <git@i509.me>
Co-authored-by: PepperBell <44146161+PepperCode1@users.noreply.github.com>
(cherry picked from commit dc716ea167)
