ModJarCollector

Enumerate the backing jars of every LOADED mod — including jar-in-jar / nested modules — so a script can import mod APIs (fabric-api, NeoForge/Forge mods, and any mod's bundled libraries) at compile time.

Separate from ClasspathCollector: Fabric's mods live on Knot (off java.class.path and off every module layer), and jar-in-jar can be missed on any loader.

Two sources: IPlatformHelper.modCodePaths for what ModList knows, orphanModuleRoots for the JiJ libraries it doesn't. A root already backed by a real file is used as-is, one inside a jar/union/memory filesystem goes through JarLocator, and only a root with no file behind it at all reaches ModJarCache.

Functions

Link copied to clipboard
private fun addKiltMods(out: MutableSet<File>)

Kilt runs NeoForge mods on Fabric, but keeps its guests in KiltLoader.mods instead of registering them, so collect's platform enumeration never sees them. Probed by class presence, Kilt being no dependency of ours. NeoForgeMod.getModFile() already points at the remapped (intermediary) jar, so what lands on the compile classpath is in the namespace the runtime uses.

Link copied to clipboard

Real backing jars / repacked class jars for every loaded mod (+ nested), deduped by absolute path.

Link copied to clipboard
private fun orphanModuleRoots(claimed: List<ModCode>): List<ModCode>

Module-layer roots ModList never sees: JiJ jars with no mods.toml (Registrate, kfflib, commonmark...). Ones JarLocator resolves are skipped — ClasspathCollector has them.

Link copied to clipboard

Every resolved module of the boot layer and of our own (the game layer), parents included.

Link copied to clipboard
private fun resolveRoot(mc: ModCode, out: MutableSet<File>, old: Map<String, String>, now: MutableMap<String, String>): Boolean

Turn a mod code path into a compiler-readable File; false if none of the three strategies works.