Migrate cross-project test source sharing to java-test-fixtures for Gradle 9.5 compatibility#11367
Conversation
profiling-controller-openjdk used
files(project(':...:profiling-controller-jfr').sourceSets.test.output)
In Gradle 8 this worked: inside the `dependencies` closure,
`project(':foo')` resolved via `Project.project(String)` -- which is a
Groovy DSL lookup fallback, since `DependencyHandler` had no
`project(String)` method -- returning the real `Project` -- which has
the `sourceSets` property.
Gradle 9.5 added `DependencyHandler.project(String)` that returns a
`ProjectDependency`, which Groovy now resolves first. The instance is a
`DefaultProjectDependency`, which has no `sourceSets` property, and
as such fails with:
```
> Could not get unknown property 'sourceSets' for project ':dd-java-agent:agent-profiling:profiling-controller-jfr' of type org.gradle.api.internal.artifacts.dependencies.DefaultProjectDependency.
```
This commit instead rely on the java-test-fixtures plugin applied
to profiling-controller-jfr to share test resources, consumer projects
now declare : testFixtures(project(':...:profiling-controller-jfr')).
Gradle 9.5 added `DependencyHandler.project(String)` returning a
`ProjectDependency`, shadowing `Project.project(String)` in
`dependencies` closures. Since `ProjectDependency` implementation do
not has a `sourceSets` property it fails the build.
The goal of using `files(project(':foo').sourceSets.test.output)` is to
share test code in other projects which is supported by the test
java-test-fixtures plugin that is already applied to the `:mongo-common`
project. Also the nine mongo driver/test consumers already declared the
correct `testFixtures(project(':...:mongo-common'))` so this commit
drops the now-broken duplicate `sourceSets.test.output` dependency
declarations.
| import java.nio.file.StandardCopyOption; | ||
| import java.util.concurrent.atomic.AtomicReference; | ||
|
|
||
| public final class JfpTestResources { |
There was a problem hiding this comment.
nit: Not sure if this a good name if this class is a bunch of static method...
Any reason code moved here, just curious.
There was a problem hiding this comment.
I'm not sure, what you mean. jfp are resources that are consumed by other tests that's also why it's in the testFixtures folder.
There was a problem hiding this comment.
To me resources are some shared data usually.
But here I can see bunch of static methods, that usually means utils.
Does it make sense now?
There was a problem hiding this comment.
Ah I see what you meant, then no the methods are really giving access to the jfp files, nothing else. (The other method are private.)
AlexeyKuznetsov-DD
left a comment
There was a problem hiding this comment.
LGTM, left minor comment.
|
/merge |
|
View all feedbacks in Devflow UI.
The expected merge time in
brice.dutheil@datadoghq.com cancelled this merge request build |
|
/merge -c |
|
View all feedbacks in Devflow UI.
|
|
/merge |
|
View all feedbacks in Devflow UI.
The expected merge time in
|
What Does This Do
Replaces two patterns of cross-project test source access that break
under Gradle 9.5:
profiling-controller-openjdkused:Since the goal was to share test resources to other projects, this fits the
java-test-fixturesplugin, this PR has a commit that migrates theprofiling-controller-jfrto this plugin, as well as its consumer projects.Note : JFP resource paths are now provided by
JfpTestResources, which extracts classpath resources to temp files as (test-fixture JARs are not accessible viaFiledirectly).Nine mongo driver/test consumers had a redundant:
testImplementation project(':...:mongo-common').sourceSets.test.outputalongside an already-correcttestFixtures(project(':...:mongo-common')). Sinceproject(':foo').sourceSetsis broken in Gradle 9.5, a commit in this PR removes the duplicate dependency declarations.Motivation
Prior Gradle 9.5,
project(':foo')in adependencies {}block resolved to the realProjectobject, which gave access to thesourceSetsproperty via Groovy magic.However, Gradle 9.5 added a
DependencyHandler.project(String)returning aProjectDependency. In Groovy DSL closures this shadowsProject.project(String), which was previously resolved as a "fallback" (sinceDependencyHandlerhad noproject(String)overload before 9.5).The actual instance returned is now a
DefaultProjectDependencyinstead, which has nosourceSetsproperties, making the build fails with:Additional Notes
Follow-up to #10402, #11272