📰 Last week we made improvements in our experimental facilities for tooling around Declarative Gradle. We have extracted the code of the DCL pipeline that Gradle runs and made more of it reusable outside of Gradle, in the clients that want to run DCL analysis in their processes – like in the IDEs and tools. Such clients can now query a more complete definition of the DCL pipeline via the Tooling API. Before these changes, the available tooling models included only the analysis schemas (the Declarative types and their members), and now they also cover the steps of analysis that Gradle runs (i.e.

pluginManagement

,

plugins

,

conventions

, settings content, project content), the aspects of each step and the connections between them. This is now enough to evaluate the declarative settings file and then apply the conventions from it to the DCL build definitions – all on the client side. Also, these changes allow clients to get the analysis results that are consistent with those in the Gradle process, without any guessing around the analysis setup and inputs. Beside that, we have added the necessary infrastructure to produce a high-level representation of the build definition's data with the conventions blended into it. Before, we were able to transfer the conventions from settings to the build definition at a lower level, which is enough to configure the model in the Gradle build but does not have a good set of abstractions for tooling. Now the clients have just the right utility to understand what declarative configuration has been applied to a project overall and where each piece of it comes from – the conventions, the build file, or a result of their combination. We are going to update the gradle-client demo app soon to show how it works, and later aid the IDE maintainers in their experiments on DCL integration, ensuring that they can reuse more of our logic and stay consistent with how things work in Gradle. Stay tuned!