This message was deleted.

I don't think this is much of a configuration cache problem as no cross-project configuration happens and the project is not accessed at runtime but at configuration time. But the idiomatic way might be a shared build service maybe.

There is no super nice idiomatic solution for some of these cases yet (I think). Especially when this extends to a composite build where you want to share a state like this across the whole build tree. I think for caching something that is downloaded, a build service is a good solution as @Vampire suggests. Another is to use an extension of the root project to store some common configuration data. But this feels a bit “dirty” (because you access the root project during configuration time). This issue is about this topic: https://github.com/gradle/gradle/issues/14697

In this particular situation the idiomatic way would be to use Gradle to download the executable just like for any other dependency and cache it globally, as well as making it available globally. The problem is that there is no such configuration included in Gradle (e.g.

exe

) that knows how to do this. The whole problem is further aggravated by the fact that executables in general are made available from random sources without metadata that would help Gradle to make it's decisions. Maybe in this case a custom ivy with custom metadata does the trick. But, having every plugin do their own thing is not a sustainable solution. I started an exe plugin a while ago that builds on top of m2 repositories. I haven't worked on it for a while but it would solve the problem. Downside is that executables need to be published to an m2 repository (e.g. MavenCentral) with Gradle metadata.