This message was deleted.
# community-support
s
This message was deleted.
v
Set the artifact view to lenient, then dependencies that cannot be resolved are ignored
e
Copy code
def ff = f.incoming.artifactView {
    lenient = true                                                                                                                                                                              
    attributes {
        attribute(Usage.USAGE_ATTRIBUTE, objects.named(Usage, "stage"))
        .. others as needed to create a full match
    }                                                                                                                                                                                                           
}
Didn't work for me, while each dependency has a matching entry, it's like these attributes aren't being picked up somehow? Wrong syntax?
Copy code
- Variant 'xyz' capability app:group:version:
                 - Unmatched attributes:
                     - Provides optimized 'false' but the consumer didn't ask for it
                     - Provides org.gradle.usage 'stage' but the consumer didn't ask for it
It's like the configuration didn't resolve, not the artifact view.
v
Can you knit an MCVE?
e
So I think I figured it out. To resolve configurations, it's attributes needs to match the exported ones in a different project. The notion of using attributes and the set of attributes used for the artifactView is different, they don't contain the ones used to describe configurations, but rather the artifacts. See com.gradle.api.artifacts.type.ArtifactTypeDefinitions. The fact that "attributes" was used in both places seems overloaded, as in the former it needed a configuration attribute, the latter a ArtifactTypeDefinition attribute.
v
But iirc artifact view should support both, as the artifacts should inherit the attributes from the configuration.
e
@Vampire In my testing, that doesn't seem to be the case. The resolved configuration must match an consumable configuration without ambiguity. When I tested, it appeared that the attributes from the configuration didn't have any impact of the matched result, only the ones pertinent to the artifacts did. Also, when I tested, attributes of the configuration didn't seem to be inherited in my case (I was hand-crafting these in groovy/build.gradle, maybe Java or Native configurations are different, but the "bare" configurations did not inherit the parent attributes).
v
No, configurations do not inherit attributes. But I was pretty sure the artifacts in the configuration do.
e
Ok! I am not arguing that they are not. Not sure on how I would test this and if it would matter at all if the resolvable configurations needs to match the exposed ones. That said, I could possibly tag the artifact with a particular attribute to indicate if it came from a Java project and needed special handling.
I could create a Gist on Github if it mattered?
d
Did you you register the attribute schema? See https://docs.gradle.org/current/userguide/variant_attributes.html#creating_attributes_in_a_build_script_or_plugin When we apply other plugins they already register the attributes for us, but in a plain project that is not done and I have seen some very strange errors (or confusing behaviours).
👍 1