but gw :utilities:explode does
Ah ok, I see.
And it makes sense.
You properly leverage task-configuration avoidance, so the code in register { ... } is evaluated pretty late.
At the time it is evaluated, you resolve the getTheFile configuration which actually is a pretty bad idea.
This then causes the list build to be evaluated at a time where afterEvaluate must not be called anymore.
I’m aware of why you most probably do
val singleFile = getTheFile.get().singleFile
doFirst {
println("we dont get here... " + singleFile)
}
You most probably had
doFirst {
println("we dont get here... " + getTheFile.get().singleFile)
}
and then got CC problems.
The better fix for that is to do
val getTheFile = getTheFile.map { it as FileCollection }
// or alternatively and the `get()` below removed
//val getTheFile = getTheFile.get() as FileCollection
// or alternatively and the `get()` below removed
//val getTheFile: FileCollection = getTheFile.get()
doFirst {
println("we dont get here... " + getTheFile.get().singleFile)
}
which then also fixes your exploding issue. (val getTheFile = getTheFile or val getTheFile = getTheFile.get() do not work as CC cannot persist Configuration, but it can persist FileCollection and Configuration is-a FileCollection, you just have to be explicit about that you only need that.
add(“asArtifact”,files(“1”,“2”)) // gradle complains you cant have multiple files as artifacts
Ah, right.
Well, it does not complain you cannot add multiple files, because you can.
It complains that you cannot add a FileCollection.
But you can without problem do files("1","2").forEach { add("asArtifact", it) }.
The problem is just, that the files have to be clear at configuration time already.
If it is only known which files will be there mid-execution, then this does not work as it must be known up-front.
If you do not know up-front which files will be in the collection, you could still have a Sync task that syncs those files to a directory known at configuration time and then configure that directory as artifact, then you would have all the dynamically generated files as artifacts properly.
add(“asArtifact”,file(“blub”)) // you can also not add another file…
Sure you can. You can call that as often as you want and need.
Is that a reasonable approach?
No, because if configuration A extendsFrom configuration B, that means that all dependencies you declare on B are automatically also decleared on A. The artifacts are not “inherited”. But as I just explained this should also not be necessary. As you suggested to create one configuration per file, I assume the files indeed are known at configuration time already and not dynamic, so just add all the files to the one configuration, just one-by-one, not as FileCollection.
Is there any documentation available on what you are talking about? I went by
https://docs.gradle.org/current/userguide/cross_project_publications.html
and i cant find any mentions of configurations.dependencyScope , or configurations.consumable
They are pretty new and still incubating (but I don’t expect much changes to them).
So they might not be documented properly yet, and not used in all places where appropriate.
But basically
isCanBeConsumed = false && isCanBeResolved = false => dependency scope
isCanBeConsumed = true && isCanBeResolved = false => consumable
isCanBeConsumed = false && isCanBeResolved = true => resolvable
isCanBeConsumed = true && isCanBeResolved = true => default for backwards compatibility, but legacy and discouraged, so don’t use it, also has no convenience helper
Also plz enable val config by configurations.registerConsumable or similar)
I’m just a user like you.
But I agree: Kotlin DSL property delegates for fixed-type configuration factory methods · Issue #27204 · gradle/gradle · GitHub
Unfortunately Gradle folks not. 
also does not change anything about the behaviour
I did not say or imply it would change anything on the behavior.
It just shows that - even while shorter - what you do is not idiomatic and not recommended,
as those new convenience methods create configurations with a narrow role like how they are meant to be used while you previously used mixed-role configurations which is not recommended.
Are you talking about what is in the documentation referred to as Variant Selection?
It is 20 days ago, so I don’t know what I said.
Which part do you mean?
I don’t think I would have suggested anything with variant selection here.
Using the configurations directly is perfectly fine if it is just within the same build that those files are shared.
declaring as an input alone doesnt fix the issue, converting everything into 