-
Notifications
You must be signed in to change notification settings - Fork 212
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Jar-in-Jar does not handle maven relocations #1119
Comments
Hi, can you try this out on |
Just tried, the issue still seems to occur on 1.7.0-alpha.2 - only the non-relocated artifacts get included. |
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. |
Cardinal Components API V6 includes an artifact relocation from the group
dev.onyxstudios.cardinal-components-api
toorg.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.The text was updated successfully, but these errors were encountered: