This message was deleted.

that's more likely an issue for whatever plugin you're using to set up the ktlint tasks

yeah, I just wondered if there was some stabdard gradle cache mechanism that might be used

I see https://github.com/JLLeitschuh/ktlint-gradle/blob/master/plugin/src/main/kotlin/org/jlleitschuh/gradle/ktlint/tasks/BaseKtLintCheckTask.kt#L73 is missing

@Input

what does

Input

do?

marks a task input, which makes it part of the computed cache key

and the thing that confuses me is that I don’t know where my custom rule jar file is that this uses. I can find the jar file in the build directory but that is not what is used it seems, so it must be something in the gradle cache somewhere

but

@Classpath

is supposed to be

@InputFiles

implicitly, so perhaps something else is not being set up properly

it’s a multi-module project and the custom rule is one module and the task is run on another module

https://docs.gradle.org/current/userguide/directory_layout.html#dir:gradle_user_home "3️⃣ Shared caches (e.g. for artifacts of dependencies)"

oh, where would it go?

it'll be used directly from the build directory of that module

oh wow it’s working again. I’m not sure what I did TBH

./gradlew --build-cache -Dorg.gradle.caching.debug=true

should print information about what is part of the cache keys

doing

./gradlew --stop

then removing the custom rules build dir and then running the task works, but I need to do the

--stop

every time, why would that be?

it sounds like something isn't getting included in the hash key that should be. you may be able to find by comparing cache debugging outputs or build scans (

./gradlew --scan

).

Have seen similar bugs where plug-in code loads something into a class-scoped (static) variable/cache, requiring a restart of the daemon to recover.

oh, that's a possibility… if the plugin is trying to be clever and runs ktlint in a cached classloader instead of using a new

JavaExec

each time or something, I can see that being a problem

Exactly. Pretty sure that's what I saw a few years back, some plug-in with odd classloader stuff. Old code that predated Gradle daemon, assuming a clean start every time.

thanks, I’ll point the plugin author towards this

that code actually seems to have this exact bug: if a jar's contents change but not its path, the classloader gets reused inappropriately