Question: Why not include dependencies as Jar in Jar
jaideepheer opened this issue ยท 2 comments
I noticed that this mod shadows the scala libraries. I feel that a better approach would be to include these libraries as Jar in Jar so that the loader can better manage the versioning of each library individually.
I just feel JiJ to be a safer approach.
The way we do it, JiJ is only of use when the library exists in the form of a Fabric mod with its own upstream. See this helpful chart. In fabric-language-scala's case, the mod "fabric-language-scala" currently serves as the upstream for those libraries.
But with this approach the library versions are frozen relative to each other.
If I want to use a newer version of one of the included libs., I will have to probably completely ditch this mod because the libs. in this are all referencing each other in the shaded package instead of using their own package.
Also what if I want to include a different lib. that uses one of the shaded libs? Won't I be forced to shade this new lib. because of the classpath difference of the standard libs included here.
I think that loom's include automatically converts the JiJ libs. into fabric mods with proper versioning and it feels like a safer approach to just use that.