This message was deleted.

Almost every time you use an explicit

dependsOn

(except if on the left-hand side is a lifecycle task) you are doing something wrong, and also if you configure paths manually. Instead you should always wire outputs and inputs together to get implicit task dependencies where needed. If you for example have a task that packages a source jar, it also needs the dependency on the generation task. Or if you have some static code analysis task, it also needs the dependency on the generation task. .....

sourceSets {
    main {
        java {
            srcDir(generateDefaultVersion)
        }
    }
}

👍 let me try that out

So in your case

"$buildDir/generated/src"

should be the output directory of the task

👍 adding src dir using task output did the trick

👌

got another "similar" failure though -> now it complains about

publishPluginMavenPublicationToMavenLocal

and

generateMetadataFileForPluginMavenPublication

missing dependency on

publishPluginJar

😞

@Vampire That’s really interesting to me what you said about

dependsOn

is in most cases wrong approach. In our code which, has seen very early versions of gradle, we have tons of custom tasks dependencies specified using

dependsOn

. Some of them were like that from the very begining, some dependOn have been added recently because of the Gradle complaining about implicit dependencies 😬 These are mostly related to various code generators we have. For example

tasks.all { task ->
...
match = task.name =~ /^generate(.*)Sources$/
  if (match && ['Debug', 'Release'].contains(match.group(1))) {
    task.dependsOn "many"
    task.dependsOn "different"
    task.dependsOn "code"
    task.dependsOn "generator"
    task.dependsOn "tasks"
    task.dependsOn "here"
    return
  }
}
...
}

How to know what is the input for the

generateDebugSources

task so output of our custom task could be input there. Is there a way to inspect any gradle task to get some more insights on its inputs and outputs?

Yeah, in our project that started pre Gradle 1.0 and grew organically, it is similar and needs quite some cleanup. Back in the days you also needed the dependencies as no implicit ones existed. Let's start with

tasks.all { ... }

. This innocent looking thing already completely disables [task configuration avoidance](https://docs.gradle.org/current/userguide/task_configuration_avoidance.html), as it requires each and every task to be realized and configured for each and every build. If

generateDebugSources

has no task actions and only exists to trigger other tasks, for example that you can generate everything after a clean checkout, that is exactly what is called lifecycle task where explicit task dependencies are the way to go. If you on the other hand depend on

generateDebugSources

for example from

compileJava

, then it is bad, as then all other tasks needing sources do not have that dependency like source jar task, javadoc task, static code analysis tasks and so on. Instead the actual tasks that generate code should have their output properly defined and then configured as source directory for the source directory set, which then carries the task dependency automatically for all tasks requesting sources and so on.

Thanks, I am aware of the configuration task avoidance feeature and that’s another thing that I want to improve in our buildsystem, but I learned we will not benefit from it since we have a plugin that compiles native code as part of the build process, and as far as I am concerned c/c++ gradle plugins are not supporting configuration cache at all. When it comes to to

generateDebugSources

I think is a task from Android Gradle Plugin. Not sure how to hook into it in any other way.

Thanks, I am aware of the configuration task avoidance feeature and that’s another thing that I want to improve in our buildsystem, but I learned we will not benefit from it since we have a plugin that compiles native code as part of the build process.

Don't confuse task configuration avoidance and configuration cache, those are completely different things. The configuration cache can skip the whole configuration phase from init scripts, over settings scripts up to configuring tasks, if an entry in the cache is available and directly start with the execution phase. The task configuration avoidance kicks in when the configuration phase actually has to be done and when used properly causes only the tasks that are going to be executed to be realized and configured, saving tremendous amount of time already in bigger builds with many projects and tasks.

and as far as I am concerned c/c++ gradle plugins are not supporting configuration cache at all

That's correct, CC is also not stable yet. It will become stable with 8.1 hopefully. Whether the native plugins are adapted until then I don't know. But hopefully at least the Nokee plugins will adapt it: https://github.com/nokeedev/gradle-native/issues/87

When it comes to to

generateDebugSources

I think is a task from Android Gradle Plugin. Not sure how to hook into it in any other way.

I'm not an Android developer, so no idea, but https://gradle-community.slack.com/archives/CA745PZHN/p1675803875548149?thread_ts=1675784054.931979&cid=CA745PZHN last post has some information about how to properly register a code generation task in Android builds.

I will give it a read, thanks for such a detailed explanation. You should be paid for the contribution you do here in this slack workspace 😉

Would be nice, yeah. 😄