When I first discovered Gradle’s incubating “Software Model” and rule-based configuration system, I was very impressed. This way of declaratively describing what a build should have, and allowing generic rules to determine how to make it, seemed to me like a massive boon to configuring complex projects whose build configurations often (in my experience) quickly become unruly and unpredictable. I couldn’t wait to start using start using this feature to transform and simplify my company’s builds.
However, a year or so later, I’m still waiting. While I used to eagerly read in the release notes for each new version of Gradle about the improvements made in this section, since Gradle 3 these seems to have dried up. While the user docs used to proclaim that this system would form the foundation of Gradle 3, this statement seems to have been quietly relaxed.
The Software Model’s functionality falls way behind the “old” configuration system. Even Groovy compilation is missing, apparently along with any sane method for someone to add it themselves (I asked about this 9 months ago, and I still haven’t had a response). Worse still, it seems like more and more functionality is being added to the “old” system, presumably diverging it further from the Software Model. My worry is that as these 2 configuration systems diverge, and more and more reimplementation work is required to bring them together, it reduces the chances of the Software Model ever becoming a first class citizen in the Gradle ecosystem.
So, my questions are:
What are the plans for the Software Model and rule based configuration? Is it on hold while more urgent issues are addressed, or is it looking increasingly likely that this was an experiment that will be dropped?
Do you have any plans for how you will bring the functionality of the old and new configuration systems together.
Based on the answers to the above, what approach would you recommend for developing new plugins? I like the configuration-order guarantees that can be given by the Software Model, so would like to use it where possible, but don’t want to find myself in the situation of having to throw all my work away and start again in a few months time if this feature never reaches maturity.
Thanks @hWorblehat for staying motivated with the software model and sorry for our late reply. We have been busy figuring out the best way to communicate our next direction. With the recent development, the ordering issue is tackled differently, and the rule engine behind the software model isn’t required anymore. Don’t get us wrong; we are still fully committed to supporting strong modeling of software domain and Gradle as a polyglot build system is here to stay.
1 . What are the plans for the Software Model and rule based configuration? Is it on hold while more urgent issues are addressed, or is it looking increasingly likely that this was an experiment that will be dropped?
We realized the rule-based configuration wasn’t solving all issues we were initially trying to solve. Since its introduction, lots have changed and we are confident we don’t need such incompatible change with the current model to achieve the same benefit.
2 . Do you have any plans for how you will bring the functionality of the old and new configuration systems together.
We will backport the native ecosystem to the current model and provide a migration path for everyone using the software model plugins. With each release, we are providing better APIs for plugin author that helps them achieve similar results the rule engine was providing.
3 . Based on the answers to the above, what approach would you recommend for developing new plugins? I like the configuration-order guarantees that can be given by the Software Model, so would like to use it where possible, but don’t want to find myself in the situation of having to throw all my work away and start again in a few months time if this feature never reaches maturity.
We recommend developing new plugins using the current model. The new Provider and PropertyState API was released as part of the backporting effort. Give them a try and give us your feedback. If you are developing plugins for the native ecosystem, we recommend doing the minimal required configuration in the rule-based engine by bridging your current model extension inside the rule-based engine.