Impact of changing=true on Build Cache

(stdoubleu) #1


I am evaluating the Build Cache feature using the --profile flag and I have noticed that for some of my submodules the compileJava task was executed instead of using the cache entry.

Having a quick view on the dependencies it seems that all affected projects have at least on dependencies with changing=true. These are dependencies which change sometimes without changing the version, but they are not considered to be snapshots dependencies by us. I know that is not clean design.

Anyway, I would like to know if the build cache feature can not be efficiently used in projects which have dependencies with changing=true?

Thank you in advance and best regards,

(Stefan Wolf) #2

Hi @stdoubleu,

if a dependency changes in a non-ABI compatible way (see compile avoidance), then the build cache key of the compileJava task will change. So it needs to be re-executed. So the question if the build cache will be efficient for your project depends on how often the ABI of the changing dependencies changes.

If the ABI changes with every build you won’t get any benefit. If the changing dependencies stay at least stable for some time, then you will have cache hits and benefit from the build cache.

Moreover, if you can isolate the effect of the changing dependencies to fewer modules via api/implementation separation you also will have more cache hits.


(stdoubleu) #3

Thank you for pointing this out. There weren’t any API changes, though.
At the moment we use only the java plugin. Migrating to the java-library plugin is still on our TODO list.


(stdoubleu) #4

Ah, now I that API and ABI are two different things :sweat_smile: