Gradle is a build automation tool.
The building and compilation of software is fairly trivial for small projects. However, as projects grow in scale and adopt a more complex structure (e.g. multi-project structure), a build automation tool quickly becomes a necessity.
It is possible to write scripts that automate the building process, however those scripts tend to be rigid. This rigidity is unacceptable due to the fast-paced nature of software development. The need for flexible yet performant build automation tools is the main driving force pushing Gradle's development.
Our architectural description focuses on how Gradle achieves its functional requirements. Throughout our architectural description, we emphasize and detail architectural elements which contribute to Gradle's performance and flexibility. Our goal is to demonstrate to the readers that Gradle can quickly build a variety of software.
As a build automation tool, Gradle should have the ability to be configured by users to build their specific project. It provides a framework used for specifying build behavior for both single and multi-project software.
To be more specific, we focus the architectural description on one of Gradle's main use cases: building Java projects.
To be flexible, Gradle makes heavy use of configuration files and run-time configuration objects which dictate the behavior of a perticular Gradle execution. These configuration files and objects are used to extend Gradle's functionality via tasks and plugins. Gradle's configuration-based approach makes use of scripting languages (Groovy and Kotlin), which introduces a learning curve.
Gradle's speed is mostly attributed to the Gradle daemon and its caching feature.
| Content | Description |
|---|---|
| Stakeholders | Describes Gradle's stakeholders alongside their interest and power with regards to Gradle's development. |
| Concerns | Identifies the main concerns which Gradle's architecture strives to satisfiy. Our AD should demonstrates that the concerns are satisfied. |
| Architectural Principles | Enumerates the architectural principles which guide Gradle's development. |
| Views & Viewpoints | Introduces our choice of views and the viewpoints from which they are derived. Describes the scope of each view and how they fit together to provide a holistic understanding of Gradle. |
| Important Scenarios | Details important scenarios and how Gradle should respond in those scenarios. This section is used to validate our AD's scope. |
| Perspective | Describes the changes brought about from applying the performance perspective on the functional and information view. Explains how our old AD failed to properly address performance related concerns. Briefly mentions concurrency and why we did not include a concurrency view in our AD. |
| Architectural Criticism | Gradle is a well architected system, however it is not without downfalls. We criticize Gradle's software design and architecture in this section. |
| Revision Plan | Our current AD is the product of our revision plan. This section details the criticism our colleagues had of our old AD. It further describes the actions that will be (and have been) taken to address the criticism. |
| Appendix | The appendix contains a variety of information and resources. Many documents in our architectural description will redirect to the appendix for more information. The appendix is not meant to and should not be read as a standalone document |