Hello, I'm migrating build.gradle files to .kts an...

# gradle

[Nino]

Hello, I'm migrating build.gradle files to .kts and so far, it was somewhat easy. I was trying to migrate this code :

task jarTest(type: Jar, dependsOn: 'compileDebugUnitTestSources') {
    from 'build/tmp/kotlin-classes/debugUnitTest'
}
configurations {
    testOutput
}
artifacts {
    testOutput jarTest
}

and I got this code, but it seems weird to create a testOutput val and never use it directly. Is there another way ?

val jarTest = tasks.register<Jar>("jarTest") {
    dependsOn("compileDebugUnitTestSources")
    from("build/tmp/kotlin-classes/debugUnitTest")
}
val testOutput: Configuration by configurations.creating
artifacts {
    add("testOutput", jarTest)
}

[CLOVIS]

it seems weird to create a testOutput val and never use it directly. Is there another way ?

There are other ways, but this is the recommended way, because it makes referring to things easier and less error-prone.

[CLOVIS]

(in general, you should use .registering instead of .creating, but specifically for Configuration, I don't think it makes a difference)

[CLOVIS]

What is your configuration for though, if you don't use it?

[Nino]

Thank you for your response !

The configuration is used in other modules so their unitTest can "depend" on this module unitTest :
testImplementation(project(path = "foo", configuration = "testOutput"))

This is basically a "in-house" java-fixture thing I guess

[CLOVIS]

What I find strange here is that it somehow guesses that jarTest is part of the configuration? I'm not an expert on the APIs, but I don't like that it's implicit

[Nino]

Yes same there's a lot of wacky stuff like that in this project (I just arrived to "fix" 10 years of Gradle technical debt) 😄

[CLOVIS]

(btw, the official way to implement something like java-fixtures is to use https://docs.gradle.org/current/userguide/cross_project_publications.html#sec:variant-aware-sharing, not to create new configurations)

[Nino]

Oh thanks I didn't know about this I'll read this one throught

[CLOVIS]

In your case, I would probably write

val testOutput: Configuration by configurations.creating
artifacts {
    add(testOutput.name, jarTest)
}

just so it's clearer that they both go together

If you have the possibility, using variants would make the build more stable for the future

[Nino]

I'll have a look, thanks a lot !

[Vampire]

it seems weird to create a testOutput val and never use it directly

Then do use it directly:

val testOutput: Configuration by configurations.creating
artifacts {
    add("testOutput", jarTest)
}

||
v

val testOutput: Configuration by configurations.creating
artifacts {
    add(testOutput.name, jarTest)
}

Or follow the same pattern you did for the task creation where you also did not use the by property delegate:

val testOutput by configurations.creating
artifacts {
    add("testOutput", jarTest)
}

||
v

configurations.create("testOutput")
artifacts {
    add("testOutput", jarTest)
}

But then as CLOVIS said, the names could derive like in your orignal code, so imho better use the first variant.

What is your configuration for though, if you don't use it?

He does use the configuration right 2 lines below declaring it, just not the variable that references it.

What I find strange here is that it somehow guesses that jarTest is part of the configuration? I'm not an expert on the APIs, but I don't like that it's implicit

It is not, he defines that by using the configuration name, just hard-coded instead of using the variable.

btw, the official way to implement something like java-fixtures

Depends on whether you want the variants to also be shared to outside projects or only withing the same build, and if the latter whether you need the full variant / attribute experience or whether explicitly asking for the configuration is sufficient. For simple cases the latter is just fine.

[CLOVIS]

He does use the configuration right 2 lines below declaring it, just not the variable that references it. It is not, he defines that by using the configuration name, just hard-coded instead of using the variable.

I went to read the docs, and indeed, the name of the artifact must match the name of the configuration. That was surprising to me, because usually the name is just used to refer to things and doesn't mean anything, but well.

[CLOVIS]

For simple cases the latter is just fine.

Good to know, thanks

[Vampire]

I went to read the docs, and indeed, the name of the artifact must match the name of the configuration. That was surprising to me, because usually the name is just used to refer to things and doesn't mean anything, but well.

Why do you call it "name of the artifact"?
It is not the name of the artifact.
It is the name of the configuration to which the artifact should be added.
Hence the parameter is also called configurationName 🙂

[Vampire]

https://docs.gradle.org/current/javadoc/org/gradle/api/artifacts/dsl/ArtifactHandler.html