Package de.griefed.serverpackcreator.api.config

Step 1 & 2: describing a server pack and proving the description is valid.

PackConfig is the central data object; everything else here either helps build it (parsing a modpack's manifest) or checks it before generation.

  • PackConfig — the recipe for one server pack: modpack directory, modloader + version, Minecraft version, which directories/mods to include or exclude, and the generation flags. The single object you hand to the checker and then to the generator.

  • ConfigurationHandler — the validator-in-chief. checkConfiguration() (and its variants) runs every check and reports the errors back so a GUI/CLI/website can show them. It delegates to the focused validators below.

  • InclusionsValidator / ModloaderValidator / ModpackDirectoryValidator — one validator per concern (the include/exclude rules, the modloader+version, the modpack directory itself), split out of ConfigurationHandler so each is small and unit-testable.

  • InclusionSpecification — one include-rule: a source, an optional destination, and optional inclusion/exclusion regex-filters. (Deliberately not a data class, to keep the plugin API stable.)

  • ExclusionFilterhow client-only mods get excluded (the matching strategy).

  • ModpackManifestParser — reads a modpack exported from a launcher (CurseForge, Modrinth, ATLauncher, GDLauncher, MultiMC/Prism) and pre-fills a PackConfig from its manifest, so users don't type everything by hand.

  • ModpackZipInspector — peeks inside a modpack ZIP to list its contents and judge whether it's a valid full modpack (has mods/config at the root).

  • ModpackSource — an enum marking where a modpack came from.

  • SupportedModloaders — the single source of truth for which loaders exist (their detection regexes and canonical names). Do not re-hardcode loader names elsewhere.

  • ConfigCheck — a small result-holder bundling each check-type's pass/fail and any errors.

See: Description