Skip to content
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

1.18 Maven builds are not useable #548

Open
pupnewfster opened this issue Mar 28, 2022 · 2 comments
Open

1.18 Maven builds are not useable #548

pupnewfster opened this issue Mar 28, 2022 · 2 comments

Comments

@pupnewfster
Copy link
Contributor

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:

withXml {
    asNode().remove(asNode().dependencies)
}

Ideally these two issues will be fixed at some point rather than requiring mods use one of the workarounds I listed above.

@DBotThePony
Copy link

Fixed by #550

@DBotThePony
Copy link

DBotThePony commented Apr 6, 2022

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants