You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
After realizing that I had missed the fact that TOP publishes to a different maven in 1.18 (#506 (comment)) I did some testing and it appears that the builds on maven don't actually work unless I forcibly make the maven only support looking for the jar directly instead of supporting the maven pom file or gradle's module metadata by using:
metadataSources {
artifact()
}
in the maven block. Alternatively each place TOP is referenced as a dependency
{
transitive = false
}
could be added after the fg.deobf(...)
The first issue is that gradle 7's module files are being uploaded (which FG has a very hard time understanding and in general if you want your mod to be able to be used on maven), which can be fixed by just disabling the module metadata like this.
The second issue is that the mapped deps are being added to the pom file, these can either be sanitized and made optional like this or by just entirely removing all deps like so if you don't actually have some:
The first issue is that gradle 7's module files are being uploaded (which FG has a very hard time understanding and in general if you want your mod to be able to be used on maven), which can be fixed by just disabling the module metadata like this.
Isn't not including from() and just including artifact() (doing it the same way as examplemod does) inside publictation configuration will achieve the same effect? Since (transitive) maven dependencies in minecraft modding scene are kinda worthless (because on runtime user either have to use mod launcher installer, or manual mod install, and not launch some kind of maven download script. So, if you want to depend on non-mod library, you usually end up with shading it or including it's compiled classes directly into assembled jar), not to mention your mod and mod you depend on might end up clashing dependencies if both mods also compile/run against 3rd mod, but have incompatible version.
And the xml patch hack only works if you are not using advanced gradle versioning features (which will cause module json file to appear), which is covered by either of solutions above.
After realizing that I had missed the fact that TOP publishes to a different maven in 1.18 (#506 (comment)) I did some testing and it appears that the builds on maven don't actually work unless I forcibly make the maven only support looking for the jar directly instead of supporting the maven pom file or gradle's module metadata by using:
in the maven block. Alternatively each place TOP is referenced as a dependency
could be added after the
fg.deobf(...)
The first issue is that gradle 7's module files are being uploaded (which FG has a very hard time understanding and in general if you want your mod to be able to be used on maven), which can be fixed by just disabling the module metadata like this.
The second issue is that the mapped deps are being added to the pom file, these can either be sanitized and made optional like this or by just entirely removing all deps like so if you don't actually have some:
Ideally these two issues will be fixed at some point rather than requiring mods use one of the workarounds I listed above.
The text was updated successfully, but these errors were encountered: