Isn't it considered best practice by now to not explicitly use

dependsOn()

for task dependencies, but to just consume output from task dependencies in as input in another task? I believe that's what I'm doing with

tasks.register<GeneratePluginDocsTask>("generatePluginDocs") {
    val kspKotlinTasks = getTasksByName("kspKotlin", /* recursive = */ true)
    val outputFiles = kspKotlinTasks.flatMap { it.outputs.files }
    inputFiles = files(outputFiles).asFileTree.matching { include("**/META-INF/plugin/*.json") }
}

but that code is not executing the

kspKotolin

tasks whose output I'm consuming... 🤷‍♂️

Isn't it considered best practice by now to not explicitly use

depen dsOn()

for task dependencies

Unless the left-hand side is a lifecycle task, correct. In other cases task output should be wired to task inputs. But you do not properly wire task output to task inputs. To start with,

getTasksByName("kspKotlin", /* recursive = */ true)

is a particularly bad idea due to several reasons. • It gets tasks from other projects, so while not being cross-project configuration you still reach into the model of other projects to get the task instances which is likewise bad and also falls under the "Don't reference other project tasks directly!" warning of https://docs.gradle.org/current/userguide/cross_project_publications.html#considerations_and_possible_solutions which is an unsafe way to share task outputs cross-project. • As it returns a plain

Set<Task>

, it also breaks task-configuration avoidance for those tasks • And it also only works with tasks that are already registered at the point where you call that method as it is not a life-collection like a

TaskContainer

. Those tasks you then

flatMap

(The

Set

-one, not the

Provider

-one) to

it.outputs.files

which then breaks the task-dependencies that would have been there. So summarized, you should switch to properly share build output cross-project as documented on the above link and if you do it properly should also get the expected task dependencies then.

Ugh... thanks for this analysis. So it means there's no way around creating a custom configuration just to share task output across projects?

No clean one, no

Oh man. Gradle used to be great once...

At least custom configuration, or custom variant

But the API for that sucks 😉

You can of course do such things and you can also preserve the task dependencies, you just need to do it right.

Right. My point is, Gradle nowadays makes it too easy to shoot yourself in the foot.

Yeah, well, backwards compatibility has a price 😄

A bit off-topic, but since you pointed out the shortcomings of

getTasksByName()

in general, is it ok to be used when not depending on task output? Like this use-case:

// Gradle's "dependencies" task selector only executes on a single / the current project [1]. However, sometimes viewing
// all dependencies at once is beneficial, e.g. for debugging version conflict resolution.
// [1]: <https://docs.gradle.org/current/userguide/viewing_debugging_dependencies.html#sec:listing_dependencies>
tasks.register("allDependencies") {
    group = "Help"
    description = "Displays all dependencies declared in all projects."

    val dependenciesTasks = getTasksByName("dependencies", /* recursive = */ true)
    dependsOn(dependenciesTasks)

    // Ensure deterministic output by requiring to run tasks after each other in always the same order.
    dependenciesTasks.sorted().zipWithNext().forEach { (a, b) ->
        b.mustRunAfter(a)
    }
}

I'm currently also fighting ugly bad-practice code I wrote back in 1.0-milestone-7 days that prevents our main project to upgrade to Gradle 8+ 😄

Hmm, but still, I just banned

allprojects

and

subprojects

from our project. I'm not going to introduce it now again 😅

As I said,

allprojects { ... }

/

subprojects { ... }

is different from using the information directly available from

allprojects

/

subprojects

🙂

I understand the semantic difference. But I really just banned "allprojects" / "subprojects" as strings from our build files, as that's an easier check than looking into each use-case whether it's acceptable.

That sample should be the sample to the above linked documentation, yes. It also links to that documentation page l linked you to.

Unfortunately, those examples do not show how to do it if you only know the (third-party) task name, and there are multiple producer tasks for which you do not know the project name.

Depends on concrete details and situation. If you for example have a convention plugin that you apply to all projects, create the outgoing configuration in all projects, and use a

pluginManager.withPlugin(...) { ... }

to react to the 3rd-party plugin being applied and then add that task as artifact to the configuration, then on consumer side just consume all projects for example.

Would

val kspProducerConfiguration by configurations.creating {
    isCanBeResolved = false
}

tasks.named("kspKotlin") {
    artifacts {
        add(kspProducerConfiguration.name, this)
    }
}

also work for the produces side?

You should not add an artifact inside a task configuration, because if you add an artifact, the resulting task will be request to configure.

A bit the other way aaround. Like that it would only be added as artifact if the task is actually going to be configured, which is bad, so yes, shouldn't be done from the task configuration action just for other reasoning 😄

Thanks. Do you also have any hints how the consumer side should look like if the project / path is unknown, and you don't want to refer to

allprojects

in

dependencies {
    sharedConfiguration(project(path = ":producer", configuration = "sharedConfiguration"))
}

Well, ideally the project path of the provider is know. At the glance, the resolution of project dependencies and external dependencies is the same. But you could depend on all projects and use a artifact view to filter failed dependencies, but I think, this requires attributes to not fail hard due to a not found requested configuration. Never tried it without attributes. Also ideally, you should use attributes instead of requesting configurations. Yes, it is complex.

For just sharing within one build using explicit configurations is usually good enough if you do not need more complex scenarios. But the Sebastian's question, if you don't want to use

allprojects

but depend on all projects, you have to list them manually. 🙂

Yeah, but don’t publish an artifact that depends on a requested configuration :)

Yeah, better not. But usually that is not the use-case for that, but to process some output of other projects, like in this case generating some documentation from the gathered files. And there it should be fine or even preferable. Otherwise the variant is also published (unless you then disable that).