JSON schemas are used by editors to validate data and provide useful insights.
The JSON schemas will be generated by the init root command. They can also be generated
using the generate schemas command.
The JSON files will reference the schemas on the user's local disk rather than hosted versions.
This allows offline editing and ensures that the schema is exactly one-to-one with the local
version of Nebula.
Existing servers will have to manually add the schema property. To see how to do this, generate
a new server and copy the $\schema value.
The schema property will need to be added to any existing distrometa files. This is the same
format as the server meta, just replace ServerMeta with DistroMeta.
More information, including sample files with json schemas, is provided
on the README.
The resolution logic was reworked so that Claritas only needs to be invoked once per supported type, ie only once for ForgeMod and LiteMod resolutions per server. The resolver now uses identifies module candidates and collects them. Claritas is invoked and the resulting metadata is stored. The module resolution then proceeds with all of this data available.
Toggleable module logic was also reworked to first accumulate all candidates and then process. This required the resolution function to optionally take a preprocess and postprocess callback to perform the necessary cleanup and transformations.
The minor rework was necessary because spawning child process is expensive, and we should only do it as often as we must to keep the application performant.
Claritas resolution also supports exceptions defined by the structure class. This is to facilitate handling of special cases (ex. Optifine).
Changed the resolver names to match the Forge Gradle versions, since that software version
determines the structure of the jar file and how it needs to be parsed.
Refactored the ForgeGradle3 resolver to conditionally execute the installer only when we
need artifacts generated by the installer. This allows the new 1.12.2 builds to be processed
without running the installer.
Changed the VersionSegemented interface to accept a libraryVersion, so we can segment within
a minecraft version.
This change is pending verification with Helios.
Tslint is deprecated, as such we have moved to eslint. Linted the project with more
stringent rules. The configuration will be changed as we figure out which rules we
should keep.
You can now use 'latest' or 'recommended' as the forge version option in the generate commands.
Two new commands are provided to query the latest/recommended version of forge.
This allows multiple versions of the same forge to be used.
Ex. Recommended 1.15 on prod, latest 1.15 on test.
Also fixed a bug with artifact classifier formatting.
Moved java executable to its own util class.
Fixed artifact resolution links for older versions of forge.
1.13 support is going to be difficult because forge does not
make anything developer friendly.
All pack.xz libraries now have their MD5s properly calculated.
Sha1 validations are performed on jar libraries. The checksums
forge provides for compressed files are neither the sha1 or md5
of the initial or extracted file. Ignoring those for now.
Still TODO is integration with baseurl. Might move both that
and base path to the .env file to reduce redundency in command processing.
TODO:
Integrate base url propagation.
Integrate PackXZExtract to calculate hashes of jar.pack.xz files.
OR ammend the distribution spec to accept different hash algos (requires helioslauncher update).
