State and future of the Gradle Software Model
Table of Contents
Introduction
We’ve received many inquiries about the status and direction of Gradle’s Software Model, especially from users building native libraries and applications.
In this blog post, we will explain the current state and future of the Software Model, and in particular how it relates to native development with Gradle. A lot of exciting improvements are planned for the remainder of 2017; see the roadmap below.
Situation with the Software Model #
In a nutshell, the Software Model is a very declarative way to describe how a piece of software is built and the other components it needs as dependencies in the process. It also provides a new, rule-based engine for configuring a Gradle build. When we started to implement the Software Model we set ourselves the following goals:
- Improve configuration and execution time performance.
- Make customizations of builds with complex tool chains easier.
- Provide a richer, more standardized way to model different software ecosystems
As we were developing the Software Model, the Gradle engineering team constantly tried to dogfood the concepts into existing software ecosystems. The Gradle plugins for building native applications is currently fully-based on the Software Model. Similarly, experimental Software Model-based plugins were developed for ecosystems like Android and Java.
Gradle adoption in the native ecosystem is picking up, and so is our investment. Since it’s inception, Gradle’s native support has proved itself as a welcome alternative for builds using Make. With its declarative and expressive model, support for different tool chains and platforms as well as features like parallel compilations, it offers a revolutionary way for building native libraries and applications.
It took us longer than expected to evolve the new configuration and Software Model and make it as powerful as the current Gradle model for Java and Android. Meanwhile, Gradle adoption skyrocketed, there are many complex builds out there using the current model and a vibrant ecosystem of 1500+ community plugins as well. We underestimated the complexity for those builds and plugins to migrate to the new model and saw understandable resistance with many of our partners to undergo this migration.
In hindsight, the scope of the new software and configuration model was too big. That is why at the Gradle Summit 2016, Hans Dockter announced that we were backporting many of its features to the current model. One year later, most of the features for the Java and Android ecosystem have been backported. This includes variant-aware dependency resolution and separation of API and implementation for Java components. Those features were game changers in terms of work avoidance and performance. Furthermore, we found other ways to drastically improve Gradle configuration performance, with more to come. There is no longer any need for a drastic, incompatible change in how Gradle builds are configured.
A way forward #
You may therefore be wondering what is happening to the Software Model. We’re in the process of porting the configuration DSL of the native support to the current model. So the declarative nature and strong modelling language will be the same. The rule engine that was part of the Software Model will be deprecated. Everything under the model block will be ported as extensions to the current model. Native users will no longer have a separate extension model compared to the rest of the Gradle community, and they will be able to make use of the new variant aware dependency management.
What does the roadmap look like? Here are the areas of focus until the end of the year:
- Current model support for native. New sets of plugins based on the current model are in development and are improved with every nightly release. They still need more work to achieve feature parity and stability, but already provide a lot of functionality. Try them out and give us feedback.
- Parallel-by-default for compile and link tasks. Performance improvements are planned for the native ecosystem by enabling parallelism-by-default to compile and link tasks. This will have a positive impact on everyone building native with Gradle.
- Transitive dependency resolution. We are porting this powerful feature from our JVM ecosystem to help native developers declare rich dependencies between native projects.
- New native plugins on current model. Our plan is to have plugins that have most of the functionality of the Software Model plugins and will also have substantial new features like build caching and external source dependencies for native.
- Improved tool chain support. We are looking at ironing out some of the wrinkles with tool chain declaration which is particularly important for embedded development.
For the most complete and up-to-date progress, we recommend having a look at the gradle-native project, the home for the native ecosystem feature planning.
User migration from Software Model plugins to the new ones will be pretty seamless. All core native tasks will be reused and the tool chain concept will be ported to the current model. We expect that a lot of your build logic can be simply reused. We will support the Software Model-based plugins for an extended period of time to ensure everyone has a successful migration.
If you are currently using, or are planning to use, Gradle to build native projects, by all means keep doing so. Gradle’s native support has proven time and time again to be more performant, flexible, and easier to use than currently available tools.
Exciting things afoot #
Today, we’re working on IDE integration and XCTest support, with out-of-the-box HTML report generation and full build scan support. Tool chain definition will also be improved to allow easier integration with alternative tool chain families; this is especially exciting for users invested in the embedded world.
For multi-repository developers, you will be happy to learn that composite builds will work for all native projects.
The new plugins will integrate with the Kotlin DSL which gives Gradle users proper IDE support including auto-completion and refactoring.
We will first implement the complete workflow for native development in the current model without any customization - i.e. no platforms, build types or tool chains configuration. By workflow we mean everything related to building binaries, as well as testing, packaging, deploying and integration with your favorite IDE. At first, the workflow will work for the most common cases. In the subsequent releases, we will proceed by adding customization incrementally to the whole workflow.
Community involvement #
Our native community is one of the most active and engaged on the forum, and we want to encourage and grow that engagement even more. Please keep helping each other find the answers you are seeking in the forum, but also engage with us by, trying the various native sample projects, subscribing to the gradle-native project and filing issues, voting on issues that are most important to you, and even consider submitting pull requests if you’re excited to roll up your sleeves and pitch in.
The best ways to stay passively up-to-date on native platform support are to subscribe to the monthly newsletter or more frequent announcements on Twitter.
We look forward to working with you to develop the best native build tool!