FabricMC / fabric-loom

Gradle build system plugin used to automate the setup of a minecraft mod development environment.
MIT License
236 stars 201 forks source link

Jar-in-Jar does not handle maven relocations #1119

Open Pyrofab opened 4 months ago

Pyrofab commented 4 months ago

Cardinal Components API V6 includes an artifact relocation from the group dev.onyxstudios.cardinal-components-api to org.ladysnake.cardinal-components-api. However, it seems that mods depending on the old maven coordinates do not get the artifacts included in their final jar. I assume this may be related to Jar-in-Jar explicitly ignoring transitive dependencies ?

This issue can be found in this repository : https://github.com/AmyMialeeMods/mialib/tree/02929a844610f5734398b25dc08f6b5f6ce90f03 Simply updating the maven group seems to make include work as expected.

modmuss50 commented 4 months ago

Hi, can you try this out on 1.7.0-alpha.2 as this code was recently re-written here: https://github.com/FabricMC/fabric-loom/pull/1080

Pyrofab commented 4 months ago

Just tried, the issue still seems to occur on 1.7.0-alpha.2 - only the non-relocated artifacts get included.

lukebemish commented 3 months ago

This seems like expected behavior in my opinion -- jar-in-jar should not pull in transitive deps by default (though I think it's possible to force it to with some work now?), and your "relocation" just publishes it as a transitive dep. There's no way for JiJ to handle this sensibly in practice, without risking unintended consequences in other cases.

You might be able to fix this on your end -- if you publish gradle module metadata, which you have disabled here, does anything improve? That file contains the full information required for relocation, not just the minimal stuff, expressed as a transitive dep, that the pom has -- and all your "relocation" is currently publishing is a pom with transitive deps (or rather, that's the only way gradle can interpret it). I don't know if it interprets the modue metadata any better, or if it even publishes it here, but it's worth a test at least.

Otherwise, I'd assume that gradle just doesn't have full support for relocation.