https://gradle.com/ logo
Join Slack
Powered by
This message was deleted.
# dependency-management
s
This message was deleted.
v
Sure, just set the correct attributes, or use the 
testFixtures(...)
helper that does it for you.
thank you 1
j
but that helper bring fixtures into fixtures/test right? I would like to get some module fixtures as implementation configuration in another module
v
It brings it in where you declare it. 
implementation(testFixtures(project("a:b:c"))
. It basically just sets the proper attributes on the dependency which you could also do manually if you prefer.
❤️ 1
thank you 1
j
For the convention of functionalTest/integrationTest, the correct way to add the fixtures to those source sets is the next snippet, right?
Copy code
dependencies {
    "integrationTestImplementation"(testFixtures(project))
}
v
There are multiple ways. Actually imho that string-y version is one of the more uglier ones. How do you create those test types? Using the test suites plugin? Then I would declare it there like the other dependencies also.
j
Do you mean if I config the test task the fixtures are automatically added?
v
No that's not at all what I said
I asked how you define the 
integrationTest
If you use the jvm test suites plugin, then I'd just declare it there like the other dependencies:
Copy code
testing {
    suites {
        val integrationTest by registering(JvmTestSuite::class) {
            dependencies {
                ...
                implementation(testFixtures(project()))
            }
        }
    }
}
j
Ah, it is under a convention plugin, that is the reason I shared it so. I am not using test suites yet. I am doing something like:
Copy code
sourceSets.named("functionalTest") { set -> set.dependencies { configureTestDependencies() } }

private fun KotlinDependencyHandler.configureTestDependencies() {
    implementation(testFixtures(project))
    ...
}
I have to investigate about test suites yet and how they work on all kind of Kotlin projects (probably they don't work on KMP right? If so, I don't want to mix yet different concepts)
v
Dunno about KMP, not used it much yet
And no idea how to properly do test fixtures with KMP
j
Indeed even text fixtures doesn’t work with kmp but I need them now to share in those source sets the fakes
v
Maybe you have to do 
project.dependencies.testFixtures(...)
j
yeah I am doing that as KotlinDependencyHandler doesn’t have it
Copy code
public fun KotlinDependencyHandler.testFixtures(notation: Any): Dependency =
    project.dependencies.testFixtures(notation)
v
Test fixtures are just a feature variant that you can select setting the right attributes. I'd expect that to work fine with KMP.
j
long time issue in Youtrack 😕
not sure about kmp, but android + kotlin doesn't work
v
The 
testFixtures(...)
helper is just setting the attributes for you
j
v
So either set the attributes manually, or use the 
testFixtures(...)
method from 
project.dependencies
j
I will try with KMP, but if there is an android target it will not work. Yep, I will use that to avoid doing that manually, really thank you 🙂
v
Well, if even Android also comes into play, I'm more out of the picture, also not doing much Android here.
I just know that AGP always does things separately and often is not compatible with standard stuff
j
I don’t know the details, Android with Java works with fixtures, but after mixing with kgp…
there are some things I don't like from AGP/KGP related to not using the standard things, for example I have created today an issue and I commented
Copy code
// KMP project
println("Sources: ${the<SourceSetContainer>().size}") // Sources: 0
println("Sources: ${the<KotlinMultiplatformExtension>().sourceSets.size}") // Sources: 83

// Kotlin JVM project
println("Sources: ${the<SourceSetContainer>().size}") // Sources: 2
println("Sources: ${the<KotlinJvmProjectExtension>().sourceSets.size}") // Sources: 2
Copy code
val topLevel: SourceSetContainer = sourceSets
val javaContainer: SourceSetContainer = java.sourceSets
val kotlinContainer: NamedDomainObjectContainer<KotlinSourceSet> = kotlin.sourceSets
Lack of consistence of different behaviors and types
Copy code
However we cannot choose between the following variants of project :hubdle-gradle-plugin:
          - runtimeElements
          - testPluginClasspath
Looks like I have to fix my custom configuration used for Gradle testkit tests
I have found this reply from you @Vampire about not indicating 
GRADLE_PLUGIN_API_VERSION_ATTRIBUTE
as it is calculated automatically, which I had to add to my custom 
testPluginClasspath
configuration some months ago. Now I am on Gradle 7.6 and on Kotlin 1.7.20. Should it be safe to delete that attribute?
Copy code
configurations.creating {
    val kotlinVersion = Version.safe(project.getKotlinPluginVersion()).getOrNull()
    if (kotlinVersion != null && kotlinVersion >= Version("1.7.0"))
        attributes { attributes ->
            attributes.attribute(USAGE_ATTRIBUTE, objects.named(JAVA_RUNTIME))
            attributes.attribute(CATEGORY_ATTRIBUTE, objects.named(LIBRARY))
            attributes.attribute(
                GRADLE_PLUGIN_API_VERSION_ATTRIBUTE,
                objects.named("7.0")
            )
        }
}
Yep it is working 🙂
Open in Slack
PreviousNext
Powered by