# Development View ## Introduction Gradle is a large open-source project. The size and scope of the system necessitates the need for a clear way for new developers to the project to contribute to Gradle while ensuring that they can understand the code and make sure their changes will not have a butterfly effect on the rest of the code base. Because of these concerns, this view is focused on how Gradle's source code is structured in order to ensure a good separation between modules. ## Module Structure Model ![Module Structure Model](https://i.imgur.com/ijo5XjS.png) ### Explaination Of Layers - Runtime Support Layer: The modules in runtime support layer can be consider as basic components to run Gradle. The modules' names start with 'base' provide some tasks and conventions that are common to most builds and add a structure to the build which will promotes consistency. The modules' names start with 'worker' will allow the running of pieces of work in the background. The other modules will provide support of java Virtual Machine, java process and the use of cache. - File Layer: The modules in file layer will allow Gradle to interact with files like source files, file dependencies, reports and so on in an easy way. - Core Layer: The core layer contains Gradle’s Project API. The Project API is available from build files and made up of 2 main interfaces: Project and Task. Project interface is main API we use to interact with Gradle. We can access all features of Gradle through this interface. Each task belongs to a project, the Task interface allows us to access each task instances. - Build Layer: The modules in build layer are responsible for initializing plugins and tasks, also allowing plugins to receive information about the operations during a build. Some modules’ names contain 'build cache' which means they are responsible for a cache mechanism that aim to save time by reusing outputs produced by other builds. So, it can allow builds to fetch these outputs from cache when the inputs not change. - Plugins Layer: The modules in plugins layer are responsible for managing plugin resolution and use, also assist with plugin development. - Utility Layer: The modules in utility are responsible for launching Gradle, the Gradle command-line interface, doing composite-builds, the execution of command, producing report after each build, and dependency-management. - Test Layer: The modules in test layer are responsible for testing. It contains Junit specific testing classes and support for general test suit. It also contains a library called 'test kit' that can help test plugins and build logic. ## Common Design Model ## Use of third-party libraries Common Processing Required - Plugins should be declared in the build script of the project before use. Gradle will automatically resolve and apply the correct plugins. Standard design - All plugins should be declared in the build script under ‘plugins’ using Groovy or Kotlin. - To apply a core plugin, short names can be used. To apply a community plugin from a portal, the fully qualified plugin id and version should be used. - Plugins can be declared with detailed information in the build script of the root project and just used in subprojects only with their name. Standard Software Components - In subproject ‘core-api’, package ‘org.gradle.api.plugins’, interfaces are used to get name of plugin from build script, find the correct version of plugin, check its validation, add to the container, and finally apply the plugin to project. # Codeline Model ## Source Code Structure - One root project folder and a sub projects folder. - Each subproject has its own folder under subprojects. - If one subproject is too large and needs to be separated into different folders, or some sub-projects need to depend on each other and do similar functionality, their names can start with the same word. ## Build, Integration, and Test Approach - The automation of the new version of Gradle will use itself. ## Release Process - When the new version of Gradle is successfully built and tested, the new binary releases will be compiled by Gradle. Then, the binary-only and complete version will be released with updated user manual, API Javadoc, DSL Reference, and Release Notes. ## Configuration Management - The source code is on GitHub. When someone wants to contribute to Gradle, a new branch needs to be created with a suitable name: developer name/project. One of the core developers will review the pull request and make a decision on it. More information can be found [here](https://github.com/gradle/gradle/blob/master/CONTRIBUTING.md). - Anyone who contribute to Gradle must follow [Gradle Code of Conduct](https://gradle.org/conduct/).