I have a build gradle that often stalls with ```2023 03 29T1

Question

I have a build gradle that often stalls with ```2023 03 29T14 18 30 913+0200 DEBUG org gradle internal resources AbstractTrackedResourceLock Daemon worker acquired lock on worker lease 2023 03 29T14 18 30 913+0200 DEBUG org gradle internal resources AbstractTrackedResourceLock Daemon worker released lock on worker lease 2023 03 29T14 18 36 716+0200 DEBUG org gradle cache internal DefaultFileLockManager Waiting to acquire shared lock on daemon addresses registry 2023 03 29T14 18 36 716+0200 DEBUG org gradle cache internal DefaultFileLockManager Lock acquired on daemon addresses registry 2023 03 29T14 18 36 716+0200 DEBUG org gradle cache internal DefaultFileLockManager Releasing lock on daemon addresses registry 2023 03 29T14 18 36 716+0200 DEBUG org gradle cache internal DefaultFileLockManager Waiting to acquire shared lock on daemon addresses registry 2023 03 29T14 18 36 716+0200 DEBUG org gradle cache internal DefaultFileLockManager Lock acquired on daemon addresses registry 2023 03 29T14 18 36 716+0200 DEBUG org gradle cache internal DefaultFileLockManager Releasing lock on daemon addresses registry 2023 03 29T14 18 46 716+0200 DEBUG org gradle cache internal DefaultFileLockManager Waiting to acquire shared lock on daemon addresses registry 2023 03 29T14 18 46 716+0200 DEBUG org gradle cache internal DefaultFileLockManager Lock acquired on daemon addresses registry 2023 03 29T14 18 46 716+0200 DEBUG org gradle cache internal DefaultFileLockManager Releasing lock on daemon addresses registry 2023 03 29T14 18 46 716+0200 DEBUG org gradle cache internal DefaultFileLockManager Waiting to acquire shared lock on daemon addresses registry 2023 03 29T14 18 46 716+0200 DEBUG org gradle cache internal DefaultFileLockManager Lock acquired on daemon addresses registry 2023 03 29T14 18 46 716+0200 DEBUG org gradle cache internal DefaultFileLockManager Releasing lock on daemon addresses registry lt ========= gt 69 EXECUTING 9m 50s gt server compileTestKotlin ``` Is there some way to diagnose this Iam running it like this `gradle d S Dorg gradle java home= usr lib jvm java 19 openjdk` already but there is nothing else coming out to give any hints on why it stalls The total build is just around a couple of minutes max usually including test suite

Sam · Answer

I have seen issues like this when running multiple gradle builds in the same directory

Henrik Johansson · Answer

This happens when just running this build and nothing else

Vampire · Answer

The output is nothing unusual If you can reproduce this you should probably run it through a debugger and then look at a thread dump when it stalls to see what is happening or where it is hanging

Henrik Johansson · Answer

I did but visualvm didn t catch much although it has been a while since I properly used it

Henrik Johansson · Answer

Not even sure if it s the kotlin compiler or gradle deamon that is the problem

Henrik Johansson · Answer

Btw are the gradle dsl always incompatible even between minor versions

Henrik Johansson · Answer

I can t upgrade to 7 6 1 from 7 5 1 because it blows up

Vampire · Answer

If you scratch the in from incompatible it is correct Breaking changes except erroneous ones or on incubating things are only done on major version changes

Henrik Johansson · Answer

Well I can t upgrade from 7 5 1 to 7 6 0 which is what you say should be supported or am I not getting how it works

Vampire · Answer

I don t know because gave no hint at all as to what your problem is which error you got and my crystal ball is at the repair shop unfortunately slightly smiling face

Vampire · Answer

An upgrade within the same major version should usually always work wihtout problem

Henrik Johansson · Answer

I got past it it was a minor thing

Vampire · Answer

What was it

Henrik Johansson · Answer

Not sure why the upgrade didn t work

Henrik Johansson · Answer

``` suites val integrationTest by registering JvmTestSuite class testType set TestSuiteType INTEGRATION TEST useJUnitJupiter dependencies implementation project ```

Henrik Johansson · Answer

The commented implementation did the trick but perhaps something else will break

Vampire · Answer

Yeah taht is an incubating API so as I said there indeed can be breaking changes and indeed in 7 6 there was one which made the dependency declarations in that block typed and better usable from Kotlin DSL

Henrik Johansson · Answer

Aha Thx for clarifying

Henrik Johansson · Answer

Doesn t seem to help with the stalls however

Henrik Johansson · Answer

I thought I should report back It was not a stall but a compiler error that simply took the compiler so very long to work out A data class that was changed to contain a new mandatory field Naturally that broke a number of tests which didn t have this field The process finished after almost 18 minutes with perhaps a dozen missing field errors There seems to be a non linear deterioration because fixing half the instances cut the time more than four times and so on progressively down to normal times Not sure what to expect but but this isn t it It s should really go much faster to bail out on this imho