For the past few years, I've been working on Forma — a Meta Build System for Android that supports Gradle.

In this series of articles, I'll explain what a Meta Build System is, why the development community might need one, and how Forma addresses many of the challenges typically encountered in large-scale projects. These concepts could also be applied to other platforms.

A quick note about Targets: In this and subsequent articles, I'll use this term instead of Gradle Project, which is often referred to as a Module.

Problem Statement

Working with Gradle build configurations can be extremely difficult, as a proper setup demands extensive knowledge of various aspects of Gradle itself, along with numerous plugins that cannot be adequately isolated. As a result, these plugins impact the entire build configuration. Add to this the dynamic nature of working with build configurations, and the result is a plethora of challenges for build engineers, as well as reduced productivity for everyone else involved in the codebase.

The decline in developer productivity is a widely recognized issue in the industry, manifesting in long build times, lengthy configuration times, extended IDE sync times, unreliable builds and tests, tremendous complexity in creating custom build steps, and much more.

Many of these problems are addressed on a case-by-case basis by individual teams, with solutions tailored to specific projects. This approach leads to a significant waste of engineering resources.

Expectations gap

I believe there is a substantial gap between the intended purpose of build systems (Gradle, in the context of this article) and their actual usage.

Gradle's extreme dynamic extensibility seemed like a sound design choice a decade ago. However, currently, there is a considerable effort by the Gradle team and community to limit the use of certain APIs (e.g., configuration time dependency resolution, isolated projects…) to make it scalable.

At present, Gradle resembles a scripting extension of the Groovy Standard Library that supports a few compilers out of the box, making it an excellent tool for prototyping(I don't believe it actually fits the Build System term).

Considering the concerns around developer productivity, it's clear that build configuration efficiency is more critical than flexibility. Bazel demonstrates that well-designed restrictions can be effective even in the world's largest source code repository.

Where to start

The first step of Forma is to determine what developers should be allowed to use in the build configuration. Ideally, this would involve fewer options than what Gradle currently offers.

The initial cornerstone of Forma is that developers should not have access to potentially harmful APIs. This concept is akin to the JVM approach, where developers are not permitted to access memory directly to maintain efficiency. Similarly, Bazel does not expose APIs that could compromise build hermeticity.

What are these potentially harmful APIs? Plugins! Plugins have access to every API imaginable, so the least we can do is eliminate them.

Of course, we can't entirely remove plugins, and some high-quality ones would require too much effort to rewrite.

For now, we'll hide plugins from developers and replace them with target declarations. This approach works for Bazel, so there's a good chance it will work for Gradle too.

This is just the first concept we need to introduce to improve developers' lives.

Conclusion

In this article, we discuss the challenges faced with Gradle build configurations and their impact on developer productivity. We introduce Forma, a Meta Build System for Android that aims to address these issues by limiting access to potentially harmful APIs and replacing plugins with target declarations. We will explore the concepts and benefits of Forma in this series of articles, starting with its initial cornerstone and its approach to improving developers' lives. Stay tuned.