This message was deleted.
# community-support
s
This message was deleted.
l
Hey Chris, There is no holistic description of these internals AFAIK. I am however surprised that resolving one configuration locks another one … unless they have an
extendsFrom
relationship. In that case, it is true that resolving a configuration locks it and all the ones it extends from, transitively.
c
I believe the configurations are independent… but I’ll do some digging to be sure.
I’ll definitely hit you up if I can’t fix it though 😄
l
👍
c
okay - it looks like it’s happening (unless I’m doing something dumb) - consider this me hitting you up!
relevant (maybe) stack trace:
Copy code
at org.gradle.api.internal.artifacts.configurations.DefaultConfiguration.preventFromFurtherMutation(DefaultConfiguration.java:1070)
        at org.gradle.api.internal.artifacts.ivyservice.moduleconverter.DefaultLocalComponentMetadataBuilder.createConfiguration(DefaultLocalComponentMetadataBuilder.java:70)
        at org.gradle.api.internal.artifacts.ivyservice.moduleconverter.DefaultLocalComponentMetadataBuilder.addConfiguration(DefaultLocalComponentMetadataBuilder.java:44)
        at org.gradle.api.internal.artifacts.ivyservice.moduleconverter.DefaultRootComponentMetadataBuilder.addConfiguration(DefaultRootComponentMetadataBuilder.java:102)
        at org.gradle.api.internal.artifacts.ivyservice.moduleconverter.DefaultRootComponentMetadataBuilder.getRootComponentMetadata(DefaultRootComponentMetadataBuilder.java:96)
        at org.gradle.api.internal.artifacts.ivyservice.moduleconverter.DefaultRootComponentMetadataBuilder.lambda$buildRootComponentMetadata$0(DefaultRootComponentMetadataBuilder.java:86)
        at org.gradle.api.internal.project.DefaultProjectStateRegistry$ProjectStateImpl.fromMutableState(DefaultProjectStateRegistry.java:352)
        at org.gradle.api.internal.artifacts.ivyservice.moduleconverter.DefaultRootComponentMetadataBuilder.buildRootComponentMetadata(DefaultRootComponentMetadataBuilder.java:84)
        at org.gradle.api.internal.artifacts.ivyservice.moduleconverter.DefaultRootComponentMetadataBuilder.toRootComponentMetaData(DefaultRootComponentMetadataBuilder.java:70)
        at org.gradle.api.internal.artifacts.configurations.DefaultConfiguration.toRootComponentMetaData(DefaultConfiguration.java:1193)
        at org.gradle.api.internal.artifacts.ivyservice.resolveengine.DefaultArtifactDependencyResolver$DefaultResolveContextToComponentResolver.resolve(DefaultArtifactDependencyResolver.java:227)
        at org.gradle.api.internal.artifacts.ivyservice.resolveengine.graph.builder.DependencyGraphBuilder.resolve(DependencyGraphBuilder.java:139)
        at org.gradle.api.internal.artifacts.ivyservice.resolveengine.DefaultArtifactDependencyResolver.resolve(DefaultArtifactDependencyResolver.java:145)
        at org.gradle.api.internal.artifacts.ivyservice.DefaultConfigurationResolver.resolveGraph(DefaultConfigurationResolver.java:186)
        at org.gradle.api.internal.artifacts.ivyservice.ShortCircuitEmptyConfigurationResolver.resolveGraph(ShortCircuitEmptyConfigurationResolver.java:85)
        at org.gradle.api.internal.artifacts.ivyservice.ErrorHandlingConfigurationResolver.resolveGraph(ErrorHandlingConfigurationResolver.java:74)
Minimal Reproducer:
Copy code
repositories {
    mavenCentral()
}

configurations {
    foo
    bar

    all {
        beforeLocking {
            logger.warn "Locking $it"
        }
    }
}

dependencies {
    foo 'org.slf4j:slf4j-api:1.7.25'
    bar 'org.slf4j:slf4j-api:1.7.30'
}

tasks.register('resolveFoo') {
    doFirst {
        configurations.foo.resolve().forEach(f -> logger.warn("Resolved $f"))
    }
}
outputs:
Copy code
$ ./gradlew resolveFoo

> Task :resolveFoo
Locking configuration ':foo'
Locking configuration ':bar'
Resolved /Users/cdennis/.gradle/caches/modules-2/files-2.1/org.slf4j/slf4j-api/1.7.25/da76ca59f6a57ee3102f8f9bd9cee742973efa8a/slf4j-api-1.7.25.jar

BUILD SUCCESSFUL in 542ms
1 actionable task: 1 executed
l
What happens if you mark
foo
and
bar
as not consumable? I will need to confirm later, but we might be indeed locking down all consumable configurations because we need the metadata for the current project, which is at the root of the resolution graph.
But I believe that limitation will be in your way since you wanted to change outgoing capabilities, so most likely on a consumable configuration
c
Copy code
canBeConsumed = false
stil locks both configurations
right - I want the capabilities of the outgoing configurations to be derived from the incoming configuration. I’m trying to reduce redundant gradle in my shading plugin