Non-Mod Dependencies

[Rongmario]

Summary

Version manage different non-mod dependencies with not having duplicates in the classpath along with jar-in-jar support

Goals

• To version manage non-mod libraries and dependencies on the fly.
• Make sure each versioned dependency is unique in the classpath, we do not allow any duplicates.
• Allow jar-in-jar for "correctly" declared dependencies.
• Make sure versioned dependencies are distinguishable from each other.

Non Goals

• Handle mods with this system.

Motivation

The issues we have had with external libraries changing method signatures and such brought up somewhat of a burden. Along with seeing the issues in imaginary versions where it has become dependency hell; where every mod is packing their own dependency. Jar-in-jar and shading being the major solutions to do so.

We have decided to propose a more centralized systems that cleanroom mod developers will be able to use, and have Cleanroom itself handle the dependency hell at runtime.

Description

Forge currently has a primitive Jar-in-Jar system that not many mods use, one notable mod that uses the system is EnderIO. EnderIO is notorious for being hard to work with in dev, as ForgeGradle never reflected Forge's own Jar-in-Jar system properl; to be able to launch with EnderIO in dev you had to jump through some hoops.

We will tackle this component in CleanroomGradle, and is actually one of the easier facets of this proposal:

1. Read the jar's manifest and get its ContainedDeps values
2. Extract jars that match the ContainedDeps values within the !jar/META-INF/libraries folder, into the mods/memory_repo/ folder.

Which is what Forge does at runtime.

However, this alone absolutely does not solve the issues of poor dependency management we have currently. Which is the second portion of this proposal.

Instead of just packing dependencies in jars, cleanroom mod developers can simply state maven artifact coordinates in their jars' manifest files... which is very similar to the existing forge functionality that can be used with the Maven-Artifact key in the manifest, but had never been documented in any capacity.

We will have to clean out this portion of the code and introduce a cleaner approach that is 100% documented and tested. While introducing proper version management.

The initial idea of version managing these non-mod libraries is quite straightforward.

Development Situation

• Example Library: org.apache.groovy:groovy-all
• Current Project depends on org.apache.groovy:groovy-all:5.0.0-alpha-5 and Project A
• Transitive Dependency from Project A: org.apache.groovy:groovy-all:4.0.18

The implementation should resolve the above situation as such:

1. Download both org.apache.groovy:groovy-all:5.0.0-alpha-5 and org.apache.groovy:groovy-all:4.0.18
2. Remap org.apache.groovy:groovy-all:4.0.18's packages to have prefix of: v4_0_18.
3. Remap Project A references to org.apache.groovy:groovy-all:4.0.18 packages to have the prefix of v4_0_18.
4. Now the environment reflects the production environment.

Production Situation

• Example Library: org.apache.groovy:groovy-all
• Mod A depends on org.apache.groovy:groovy-all:5.0.0-alpha-5
• Mod B depends on org.apache.groovy:groovy-all:4.0.18
• Mod C depends on org.apache.groovy:groovy-all with the version range of 3.0.0 <= x <= 5.0.0

The implementation should resolve the above situation as such:

1. Grab every mod's dependencies
2. Acknowledge org.apache.groovy:groovy-all as being a library that is needed to be downloaded
3. Evaluate Mod A, Mod B, Mod C's version requirements for org.apache.groovy:groovy-all
4. The evaluation should result in that only org.apache.groovy:groovy-all:4.0.18 and org.apache.groovy:groovy-all:5.0.0-alpha-5 be downloaded, since Mod C accepts either of those versions already
5. Remap every version that isn't the newest one, in this case, org.apache.groovy:groovy-all:4.0.18, and the Mod B that depends on it.

The most complex part of this being the remapping portion, the shadow plugin for gradle does a terrific job at doing this, but at compile time.
This is the initial proposal and will be subjected to revisions and scrutiny. Hence the content may change.

Dependencies

• CleanroomGradle

References

No response

Guidelines

• I have and will continue to adhere to the guidelines

[kappa-maintainer]

Maybe we will need this to resolve version information or even download library for mods
https://maven.apache.org/resolver/

[TheLMiffy1111]

This dependency system should use a separate file for info instead of the manifest

[kappa-maintainer]

My current implementation in exp branch is:

1. Check for "NonModDeps" manifest when adding mod to classpath
2. Add files in "ContainedDeps" to classpath before adding the mod jar

[vfyjxf]

Allowed to include coremod via jar in jar
With jar in jar, we can directly eliminate the illegal use of minecraft classes in the coremod stage by controlling the coremod dependencies.