This message was deleted Gradle Community #dependency-management

Join Slack

This message was deleted.

# dependency-management

Slackbot

04/08/2022, 8:26 AM

This message was deleted.

Vampire

04/08/2022, 9:01 AM

The question is, where does it come from? In a simple project applying

java-library

for example I only have • apiElements • mainSourceElements (i) • runtimeElements • testResultsElementsForTest (i)

Tapchicoma

04/08/2022, 9:02 AM

and if you run

outgoingVariants --variant default

Louis Jacomet

04/08/2022, 9:12 AM

default

has no attributes set by the Java plugins normally. It should be considered a legacy configuration and no plugins should add attributes to it. I suspect that the Kotlin plugin ends up adding attributes to it as I remember it doing that for all consumable configurations.

Tapchicoma

04/08/2022, 9:15 AM

I am getting following variant selection issue:

Copy code

Could not determine the dependencies of task ':kotlin-gradle-plugin-idea:test'.
> Could not resolve all task dependencies for configuration ':kotlin-gradle-plugin-idea:testRuntimeClasspath'.
   > Could not resolve project :kotlin-gradle-plugin.
     Required by:
         project :kotlin-gradle-plugin-idea
      > The consumer was configured to find a runtime of a library compatible with Java 8, packaged as a jar, preferably optimized for standard JVMs, and its dependencies declared externally, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'jvm'. However we cannot choose between the following variants of project :kotlin-gradle-plugin:
          - default
          - gradle70RuntimeElements
          - runtimeElements
        All of them match the consumer attributes:
          - Variant 'default' capability org.jetbrains.kotlin:kotlin-gradle-plugin:1.7.255-SNAPSHOT declares a component, preferably optimized for standard JVMs, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'jvm':
              - Unmatched attributes:
                  - Doesn't say anything about its component category (required a library)
                  - Doesn't say anything about how its dependencies are found (required its dependencies declared externally)
                  - Doesn't say anything about its target Java version (required compatibility with Java 8)
                  - Doesn't say anything about its elements (required them packaged as a jar)
                  - Doesn't say anything about its usage (required a runtime)
          - Variant 'gradle70RuntimeElements' capability org.jetbrains.kotlin:kotlin-gradle-plugin:1.7.255-SNAPSHOT declares a runtime of a library compatible with Java 8, packaged as a jar, preferably optimized for standard JVMs, and its dependencies declared externally, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'jvm':
              - Unmatched attribute:
                  - Provides attribute 'org.gradle.plugin.api-version' with value '7.0' but the consumer didn't ask for it
          - Variant 'runtimeElements' capability org.jetbrains.kotlin:kotlin-gradle-plugin:1.7.255-SNAPSHOT declares a runtime of a library compatible with Java 8, packaged as a jar, preferably optimized for standard JVMs, and its dependencies declared externally, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'jvm'

Seems

default

and

runtimeElements

has same capability and then Gradle fails to select one

Tapchicoma

04/08/2022, 9:16 AM

or there is way to say Gradle to select variant with most matching attributes?

Vampire

04/08/2022, 9:17 AM

Ah, ok if I use

--all

, I also see

default

and

archives

legacy ones, just never had a problem with them.

Vampire

04/08/2022, 9:18 AM

I think it automatically selects the one with the most matching attributes, except if there are ones that are too similar like both have the same 4 attributes and both have 1 unmatched but different, then they are equal or something like that. What does

outgoingVariants --all

say for you?

Tapchicoma

04/08/2022, 9:20 AM

I think it automatically selects the one with the most matching attributes

runtimeElements

has the most matching attributes, though

default

has 5 without any value

Vampire

04/08/2022, 9:21 AM

Can you show what that command says, or is it confidential?

Tapchicoma

04/08/2022, 9:21 AM

What does
outgoingVariants --all
say for you?

https://ge.jetbrains.com/s/u2y5ykm5ynhkk/console-log

Tapchicoma

04/08/2022, 9:30 AM

I suspect that the Kotlin plugin ends up adding attributes to it as I remember it doing that for all consumable configurations.

You are right - there are 2 attributes seems added by KGP. I will open an issue for this. Is there a way to detect such legacy configurations?

Vampire

04/08/2022, 9:31 AM

Hm, seems I still don't fully understand the variant selection process. If you have a variant of a plugin For gradle 7+ and one for older, it selects the proper ones, though they have the same attributes, just one has additionally the Gradle version attribute. So no idea, why it does not simply select the right one. Maybe @Louis Jacomet can tell. But as he already said, it is probably the Kotlin plugin adding attributes to legacy configurations. For me

default

has no attributes at all, in your case it has

org.gradle.jvm.environment

and

org.jetbrains.kotlin.platform.type

. So I guess the Kotlin plugin should be fixed and as a work-around on the producer side, you remove the attributes the plugin added. Or as a consumer-side work-around you can use a component metadata rule to remove the attributes.

Vampire

04/08/2022, 9:35 AM

Is there a way to detect such legacy configurations

My first guess would be, if they are resolvable and consumable

Vampire

04/08/2022, 9:37 AM

(l) Legacy or deprecated configuration. Those are variants created for backwards compatibility which are both resolvable and consumable.

Vampire

04/08/2022, 9:37 AM

From the legend of

outgoingVariants

Tapchicoma

04/08/2022, 9:37 AM

Or as a consumer-side work-around you can use a component metadata rule to remove the attributes.

Do you have such example nearby? I am looking into

ComponentMetadataRule

and seems it only possible either modify existing or add new one attribute

Tapchicoma

04/08/2022, 9:42 AM

FYI to follow: https://youtrack.jetbrains.com/issue/KT-51913

Vampire

04/08/2022, 9:45 AM

My first guess would be, if they are resolvable and consumable

Yes, I was right:

Copy code

if (configuration.isCanBeConsumed() && configuration.isCanBeResolved()) {
    type = ReportConfiguration.Type.LEGACY;
}

👍 1

Louis Jacomet

04/08/2022, 9:46 AM

I cannot immediately explain why there is confusion in resolution here. It must be something with disambiguation failing to find an intersection. See https://gradle-community.slack.com/archives/CAHSN3LDN/p1649317045662649?thread_ts=1649275223.542899&cid=CAHSN3LDN for details on how it works.

👀 1

Vampire

04/08/2022, 9:48 AM

Do you have such example nearby? I am looking into
ComponentMetadataRule
and seems it only possible either modify existing or add new one attribute

tbh, I never tried, I just assumed it works. But even if you just can modify existing ones and add new ones, then modify one of the two to an incompatible value and it should hopefully work

👍 1

Louis Jacomet

04/08/2022, 9:53 AM

This is a project dependency, CMR will not apply to it. Instead you should modify the project directly.

👍 1

Vampire

04/08/2022, 9:57 AM

Yeah, if it is a project dependency of course, there you have the producer under control. Should have been clearer.

Tapchicoma

04/08/2022, 10:22 AM

then modify one of the two to an incompatible value and it should hopefully work

I've changed one of attribute values in

default

variant and that solved the issue ✅ Thank you for discussion 👏

👌 2

4 Views

Open in Slack

Previous Next