:tada: Gradle 9.6.0-rc-3 is out! <https://docs.gra...
# releases
c
party gradlephant 2
r
We're almost there addressing all deprecation warnings. hitting a ton
➕ 1
We run into a regression. its fixable on our end but probably worth noting. I can only share the buildkite logs on this but the class in question is in our public repository:
Copy code
Artifact UUID: 019ed6d7-fef0-4bb3-bbea-9e7be040f3bd
FAILURE: Build failed with an exception.
* What went wrong:
Could not determine the dependencies of task ':distribution:docker:transformDockerContext'.
> Could not resolve all dependencies for configuration ':distribution:docker:detachedConfiguration1'.
   > Problems writing to Binary store in /opt/buildkite-agent/.gradle/.tmp/gradle1695853813216432510.bin (exist: true)
* Try:
> Run with --info or --debug option to get more log output.
> Get more help at <https://help.gradle.org>.
* Exception is:
org.gradle.api.internal.tasks.TaskDependencyResolveException: Could not determine the dependencies of task ':distribution:docker:transformDockerContext'.
	at org.gradle.api.internal.tasks.CachingTaskDependencyResolveContext.getDependencies(CachingTaskDependencyResolveContext.java:70)
	at org.gradle.execution.plan.TaskDependencyResolver.resolveDependenciesFor(TaskDependencyResolver.java:49)
	at org.gradle.execution.plan.LocalTaskNode.getDependencies(LocalTaskNode.java:151)
	at org.gradle.execution.plan.LocalTaskNode.resolveDependencies(LocalTaskNode.java:125)
	at org.gradle.execution.plan.DefaultExecutionPlan.discoverNodeRelationships(DefaultExecutionPlan.java:183)
	... 162 more
Caused by: java.lang.RuntimeException: Problems writing to Binary store in /opt/buildkite-agent/.gradle/.tmp/gradle1695853813216432510.bin (exist: true)
	at org.gradle.api.internal.artifacts.ivyservice.resolveengine.store.DefaultBinaryStore.write(DefaultBinaryStore.java:61)
	at org.gradle.api.internal.artifacts.ivyservice.resolveengine.result.StreamingResolutionResultBuilder.visitEdges(StreamingResolutionResultBuilder.java:177)
	at org.gradle.api.internal.artifacts.ivyservice.resolveengine.graph.CompositeDependencyGraphVisitor.visitEdges(CompositeDependencyGraphVisitor.java:45)
	at org.gradle.api.internal.artifacts.ivyservice.resolveengine.graph.builder.DependencyGraphBuilder.assembleResult(DependencyGraphBuilder.java:654)
	at org.gradle.api.internal.artifacts.ivyservice.resolveengine.graph.builder.DependencyGraphBuilder.resolve(DependencyGraphBuilder.java:164)
	at org.gradle.api.internal.artifacts.ivyservice.resolveengine.DependencyGraphResolver.resolve(DependencyGraphResolver.java:110)
	at org.gradle.api.internal.artifacts.ivyservice.ResolutionExecutor.doResolve(ResolutionExecutor.java:424)
	at org.gradle.api.internal.artifacts.ivyservice.ResolutionExecutor.resolveGraph(ResolutionExecutor.java:312)
	at org.gradle.api.internal.artifacts.ivyservice.ShortCircuitingResolutionExecutor.resolveGraph(ShortCircuitingResolutionExecutor.java:90)
	at org.gradle.api.internal.artifacts.ivyservice.DefaultConfigurationResolver.resolveGraph(DefaultConfigurationResolver.java:126)
	at org.gradle.api.internal.artifacts.configurations.DefaultConfiguration$1.call(DefaultConfiguration.java:672)
	... 186 more
Caused by: java.lang.ClassCastException: class org.elasticsearch.gradle.Architecture cannot be cast to class org.gradle.api.Named (org.elasticsearch.gradle.Architecture is in unnamed module of loader org.gradle.internal.classloader.VisitableURLClassLoader$InstrumentingVisitableURLClassLoader @28a4d17; org.gradle.api.Named is in unnamed module of loader org.gradle.internal.classloader.VisitableURLClassLoader @619a5dff)
l
Thanks for the report, taking a look. What's the fix on your end looking like?
r
just implementing 'Named'
l
Could it be that the stacktrace is truncated? I seem to be missing the place where the
ClassCastException
is thrown
r
yeah i cutted it down
let me find the log file
l
If you can share the full one, here or to me directly please 🙂 Current search shows we gate all those casts with a check first ...
This is new in RC3? Which version of Gradle does this work with? 9.5.1 or older? The code is old, and effectively, non basic attributes must implement
Named
. This is just not really document AFAICT, and not enforced when creating attributes.
r
yes it did work with 9.5.0. just updating to 9.5.1
again, we can fix it on our end. just brought it as others might run or will run into it
maybe an ordering issue?
l
We handle attributes in funny ways inside Gradle. Because the ones defined in the build script can be rich, but anything coming from 3rd party libraries is effectively String based. So maybe something changed in that stack that causes an unexpected value to reach that code. Thanks for confirming this is not isolated to RC3 ... cause the changes were very much unrelated 🙂
So, took me a while, but we do document the need to implement
Named
. Given you did not, how were you creating values for your attribute? All the examples in doc for rich attributes leverage
objects.named
r
we have this 🙈 :
Copy code
val dockerBuildTasks = Architecture.values().associateWith { architecture ->
    val baseName = if (architecture == Architecture.AARCH64) "Aarch64" else ""
    val upstreamContext = configurations.detachedConfiguration(dependencies.create("org.elasticsearch:docker")).apply {
        attributes {
            attribute(Attribute.of(Architecture::class.java), architecture)
            attribute(Attribute.of(DockerBase::class.java), DockerBase.WOLFI)
        }
    }
...
}
l
Right, your type is an enum and thus you use its values directly. That's definitely not a pattern we have been thinking about. There is a high chance we will keep this breakage in, sorry. But we might enforce the
Named
relationship further in 9.7.0.
r
thats totally fine
from all the breakages 9.6 brought, this was one of the smaller issues 😄
l
Real breakage or tons of deprecations that you count as breakage?
r
deprecations
👍 1
p
Attributes are strange (untyped). Named is incredible strange too. The combination is strange. And I also don't know why a NDOC does not require the type to extend Named.