Suggestion: A Maven Repo For Integrating AppleSkin Into Build Environment
alexis-evelyn opened this issue ยท 5 comments
I'm trying to add AppleSkin into my build environment through gradle, however, it appears there's no Maven repo for AppleSkin.
Edit: I got around the lack of Maven repo by using Jitpack to compile the source code on the fly before it converts the binaries to a temporary maven repo. I do still recommend hosting an official repo though. You can use the official Maven repo if you want or try to get onto https://maven.fabricmc.net/ if you want to use the official fabricmc repo.
Set this up for Fabric: https://github.com/squeek502/AppleSkin/tree/1.16-fabric#for-mod-developers
Haven't published the Forge version because I haven't figured things out for Forge yet.
Got something setup for Forge now too: https://github.com/squeek502/AppleSkin#for-mod-developers
This is a priority now that we have an API package. Was looking into using GitHub packages, but it requires users to be authenticated to download artifacts which seems like a hassle. Could use https://www.ryanliptak.com/maven/ like I did for AppleCore.
The bigger thing that needs to be done is the necessary changes to build.gradle
, setting up CI, etc.
Going to use this comment as my notes while investigating this whole thing. Will edit this comment as I work on things.
Fabric:
- Most mods seem to publish APIs as separate modules (example). This doesn't seem totally necessary, though
- Can exclude all transitive dependencies by doing
modApi('package.path:module:version:api') { transitive = false }
- The API jar seems to still need a
fabric.mod.json
in it to be able to load properly, otherwise I was getting this error on startup:
java.lang.LinkageError: loader constraint violation: when resolving field "EVENT" of type net.fabricmc.fabric.api.event.Event, the class loader net.fabricmc.loader.launch.knot.KnotClassLoader @3aa078fd of the current class, squeek.appleskin.example.AppleSkinEventHandler, and the class loader 'app' for the field's defining class, squeek.appleskin.api.event.FoodValuesEvent, have different Class objects for type net.fabricmc.fabric.api.event.Event (squeek.appleskin.example.AppleSkinEventHandler is in unnamed module of loader net.fabricmc.loader.launch.knot.KnotClassLoader @3aa078fd, parent loader net.fabricmc.loader.launch.knot.KnotClassLoader$DynamicURLClassLoader @1f9e9475; squeek.appleskin.api.event.FoodValuesEvent is in unnamed module of loader 'app')
- The API's
fabric.mod.json
needs blank entrypoints/mixins arrays, though. Seems like REI uses a fake one for its API jar - Still not really sure what the best way to include an API is in order to use it only when the mod is installed. It seems like entrypoints might be the most user-friendly way. That way, e.g. mods could register an "appleskin" entrypoint and do all the event handling in there. Then, if the mod is run without AppleSkin installed, it's totally fine.
- It seems possible to omit the
fabric.mod.json
when including theapi
dependency withmodCompileOnly
, which is possible to use when using an entrypoint to register the events. This seems like the best way to go; not sure if other Fabric mods are doing this sort of thing though - I think enforcing
modCompileOnly
for the api jar is a decent way to do it (i.e. don't include a fabric.mod.json in the API jar). Mods shouldn't need toinclude
the AppleSkin API on its own as a jar-in-jar if they use the entrypoint, and doing it this way means that AppleSkin doesn't pollute the classpath/dependencies of users of the API.- Here's some code to generate a dummy fabric.mod.json at build-time if we ever want to include one in the API jar:
// within task apiJar() {
def modJson = new File(project.buildDir.getPath(), "api-resources/fabric.mod.json")
modJson.getParentFile().mkdirs()
modJson.write('{"schemaVersion": 1, "id": "appleskin-api", "version": "'+project.mod_version+'", "name": "AppleSkin API"}', 'UTF-8')
from (project.buildDir.getPath() + "/api-resources") {
include('**')
}
Forge:
- Haven't messed with Forge yet