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

add dependency with classifier? #959

Open
KaitlynEthylia opened this issue Jan 14, 2025 · 3 comments
Open

add dependency with classifier? #959

KaitlynEthylia opened this issue Jan 14, 2025 · 3 comments
Labels
bug Relates to or reports a bug in the codebase eventually Something to look into or add eventually, but not immediate FG6 This request is for FG 6 won't fix Issue is not a real issue or not something worth fixing

Comments

@KaitlynEthylia
Copy link

I'm trying to add the slim version of MixinExtras, but if I just add :slim to the end, I get an error telling me "Cannot add attributes or capabilities on a dependency that specifies artifacts or configuration information" and I haven't been able to figure out any other way to do it

@Jonathing
Copy link
Member

Jonathing commented Jan 14, 2025

Can you send me an example of even your entire buildscript so I can reproduce? In my own projects I just Jar-in-Jar the main MixinExtras jar.

@Jonathing
Copy link
Member

Ok, I just tested this myself and am getting this problem. It looks like another implementation detail in ForgeGradle 6 where because jarJar is a configuration type, the data for how to handle those dependencies are stored as attributes. And you can't store attributes on module dependencies that specify specific classifiers or artifacts, because Gradle tends to use attributes to resolve those artifacts itself.

The icing on the cake is that ForgeGradle 6 has fallbacks in place if you don't set the version. For example, if you don't call jarJar.ranged(), what is SUPPOSED to happen is ForgeGradle makes a version for you like this: [${version},). However, this doesn't happen, and the only thing returned in version, resulting in the ranged version format error throwing.

So yeah, it's a complete fucking mess. The best I can do is fix the that one bug I mentioned above where the JarJar metadata defaults to having a ranged version of version and not [version,), so that if you don't call jarJar.pin() or jarJar.ranged(), it will still work. I've spent hours today trying to find some sort of suitable workaround, but I can't find any way of arbitrarily asking Gradle to use a specific classifier of a jar through a normal ModuleDependency.

@Jonathing
Copy link
Member

Yeah scratch that, this issue is a lot more deep-rooted than I thought. It turns out that even after my makeshift fix of defaulting the version range, JarJar will still use the unclassified jar to put into the jar file. So yeah, I'm completely out of options for this. I'll just make sure to keep this in mind when I work on newer Gradle-related projects.

@Jonathing Jonathing added bug Relates to or reports a bug in the codebase eventually Something to look into or add eventually, but not immediate won't fix Issue is not a real issue or not something worth fixing FG6 This request is for FG 6 labels Jan 16, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Relates to or reports a bug in the codebase eventually Something to look into or add eventually, but not immediate FG6 This request is for FG 6 won't fix Issue is not a real issue or not something worth fixing
Projects
None yet
Development

No branches or pull requests

2 participants