Hello, I have been trying to allow running Deno (Light node)/Esbuild and other native binaries as a Maven/Gradle Java library. Allowing arch specific dependencies already works fine in Maven and in NPM ecosystems and I thought it would also work on Gradle as documented (doc about variants). But it didn't work at all, when debugging I can see it's using the module file but it's not checking the arch native stuff at all. I must be missing something. I found a few related issue (such as https://github.com/gradle/gradle/issues/34845), but didn't find a solution to my issue yet.

As the issue by @Jendrik Johannes you linked to explains, those attributes are currently only semantically defined for buidling native stuff with Gradle, not for consuming native variants in Java projects. You can set those attributes and a consumer can request those attributes and then it will work. Also, as all your variants have the attributes, your consumer will be notified that Gradle does not know which to pick so is hinted at setting these attributes. The attributes are "just" not set automatically by Gradle on any resolvable configurations.

@Vampire ok but why not extend then to all kind of variants?

Why do you ask me? I'm just a user like you.

Ah ok 🙂

That issue you linked to exactly asks for defining those attributes generally and not only for building native libs. Part of that might also be that they are set on the default resolvable configurations.

the things that trouble me is the doc which doesn't explain if those attributes are set or not, and the PR makes it even more confusing IMO as it generalise it to JVM also (while in the end it's not working out of the box)

I'm not sure what you are talking about and especially what PR you refer to. You can set any attribute on any variant and consume any attribute on any resolvable configuration. It is the burden of the inventor / maintainer of an attribute and its values to define the concrete meaning of attributes and their values, their compatibilities, and their disambiguation rules. Doing this correctly is far from trivial. Those two attributes are simply not officially defined in the context of a JVM project. But that does not stop libraries releasing variants with those attributes or consuming them. It is just not centrally and officially defined what the semantics should be in that context.

ok so in theory, I could create a plugin that allows to set those properties in the user project?

To communicate with the Gradle folks about an issue or pr, better write comments to the respective project

I am not sure I get what you mean here "especially without an official meaning for the attributes might be questionable though"

since they are now defined as for the JVM too

Ah, nice, I didn't know that PR and that it was merged, so indeed from 9.3.0 on they are properly defined, yeah, unless the commit gets reverted before release (such things happened in the past).

what I don't get is why some of those are actually pre-configured out of the box in the user project and some other are just semantic

I think big-guy stated it at https://github.com/gradle/gradle/issues/34845#issuecomment-3293230632. I'd exepect that somewhen in the future maybe it will be in Gradle core that also those are added. Actually adding them lightly might be a breaking change, as resolution might change by that. When previously a variant was selected that does not have those properties and then a variant that has them is selected for a library. This might be a good and intended change, but nevertheless it might be breaking.

Ok I created a plugin which should be available soon if it gets approved

Whoa, that is a quite aggressive plugin. I don't think you should just set these attributes on each and every configuration. Even setting them only on the resolvable ones might be questionable. And also never use

all

, but always

configureEach

when handling domain object collections you do not own. Also, you should neither invent new attributes that are named like the official ones but have a totally different type, and you should also usually not declare the attributes in the attributes schema if you are not the maintainer of those attributes but apply the plugin that registers them and also adds compatibility and disambiguation rules as necessary. And it probably also make sense to set the attributes individually even if one of the values cannot be determined. 🤷‍♂️

Those attributes will just serve in case there are specified in the variant, why would it be a problem for other cases?

You are not using the official ones

Ok, that's great input, I am not familiar enough with all this (I am just here to make my lib compatible for Gradle users)

I suppose we could add rule that only apply if the variant specify the attribute

No, absence is by definition compatible

"Instead apply the plugin that declares those attributes" I am not sure what you mean here

I mean apply from your plugin the plugin that declares those attributes on the attribute schema and sets up its compatibility and disambiguation rules.

ok I'll do that