Changes to buildSrc will always cause any non core task to be out of date?

Help/Discuss
1

Hello.

So I have a setup somewhat similar to https://docs.gradle.org/current/samples/zips/sample_sharing_convention_plugins_with_build_logic-kotlin-dsl.zip
I defined a task in the project build-conventions like this

@CacheableTask
abstract class MyTask :DefaultTask() {

    @get:InputDirectory
    @get:PathSensitive(PathSensitivity.NONE)


    abstract val  inputDir: DirectoryProperty
    @get:OutputDirectories
    abstract val  outputDir: DirectoryProperty

    @TaskAction
    fun go() {
        //ignored for simplicity
    }
}

And then use it somewhere in the project…

tasks.register("hi",MyTask::class){
    inputDir=project.layout.projectDirectory.dir("src")
    outputDir=project.layout.projectDirectory.dir("build")

}

Now my observation is that any and all changes to the “buildSrc” project will always cause my task to be out of date.

Task ':list:hi' is not up-to-date because:
  Class path of task ':list:hi' has changed from ea27f7d10c6a0af4b523813675cd1d1a to 9a2670e1f656a1bcec84ba710b5aaa9c.

This is fairly odd, because the default tasks of gradle like javacompile,javaexec… are not
affected by this-> these tasks seems to not track their class path/classloader and stay up to date after I change somthing.
My current theory is that gradle treats its own core task somewhat differently and I really need to avoid using a buildSrc to not trigger unwanted rebuilds or is there something that i am missing?
So could be something like telling gradle: my tasks really doesn’t do aditional classloader black magic or just put my task on a different classloader if you dont believe me…

Best regards ,
Thorsten

2

I don’t get why you think “these tasks seems to not track their class path/classloader”.
If you change buildSrc you do not change the Gradle distribution.
So the classpath / classloader of the built-in tasks are unchanged.
The buildscript classpaths changed, so you need to reconfigure everything in any case.
And then everything that is touched by something from your buildSrc has a different classpath and thus is of course out-of-date, you could have done arbitrary changes that influence the outcome.
It would be pretty fatal if you could disable that.

And yes, that’s one of the big drawbacks with buildSrc, especially in bigger builds with many projects where some custom build logic is needed just in some projects and some others in some other projects and in some projects none of them.

buildSrc classes and dependencies are put to a classloader that is in the ancestry of all build script class loaders, so always change the classpath of each and everything. With an included build, or multiple, or multiple projects in an included build, …, you can make it in a way that only the things that actually use a specific part of the build logic are affected.

3

Well that sucks incredibly, thanks anyway

1 Like