Figure 8: A more detailed view at the core source code of Gradle

Common processing

Just like any other large system, Gradle has separate code modules for tasks which are common to other modules. A few of Gradle's common used modules have been identified in the subprojects/core folder:

• A central, common logger is used. The Simple Logging Facade for Java (SLF4J) is used to keep track of all the logs made by Gradle. This is also used by the -debug option to allow the user to easily debug their code.
• Moreover, multiple utilities are made by the team to be used throughout the project. In the src/util folder, many utilities are listed, such as a nameMatcher, a clock and a swapper, which can be easily used by other modules.
• Because of Gradle's high dependency on external plugins, its API can also be considered as common process. The tooling-api provides the user with the needed dependencies on those plugins.

Standardization of design

Since Gradle is an open source platform, everyone is free to contribute to the repository on GitHub. Seeing as multiple contributors are influencing Gradle, the core developers have standardised aspects of the design of the system to make it as maintainable, reliable and technically cohesive as possible. There is not a lot of information available about the general design of the platform, but the core developers have made some guidelines for new contributors to keep the overall code quality high and the licences applicable. The most important aspects of contributing to Gradle are discussed in the CONTRIBUTIONS.MD file:

• Contributors have to use git and have a GitHub account to be able to fork the GitHub repository gradle/gradle
• Use a text editor or IDE (IntelliJ IDEA CE is recommended) to make changes
• Document changes in the User Guide and DSL Reference (under subprojects/docs/src/docs)
• Users are not allowed to put in their names in @author Javadoc field
• Write a solid commit message, explaining what has been done in the proposed change
• Sign the CLA, which defines the terms under which the intellectual property has been contributed to Gradle
• Make a pull request using the PULL_REQUEST_TEMPLATE.md and wait for their code to be reviewed by a Gradle core developer

There are no concrete guidelines of using design patterns in the development of Gradle. However, when examining the code, the factory, builder, Singleton or a combination of these design patterns have been identified many times. For example, the GroovyCompilerFactory.java and DefaultDirectoryFileTreeFactory.java are two classes built according to the factory design pattern.

The implementation workflow is flexible. Core Gradle developers are allowed to commit directly into the master, other contributors have to use pull requests. These pull requests are labelled by developers, assigned to issues (if applicable) and categorised before merging.

Standardisation of Testing

By standardising the test approaches, technologies and conventions, the overall testing process remains consistent and has a higher pace. In this section, Gradle’s efforts to achieve this are reviewed.

The Gradle project uses its own Gradle build tool as its build tool of choice, which initiates all tests. All new contributions need to include two things in terms of testing. First of all, it needs to provide new Unit Tests, using the Spock framework for any novel logic introduced. In addition, integration test coverage of the new bug/feature should also be provided. Afterwards, TeamCity automatically checks the compatibility of the introduced code, preventing any unexpected failures. To give some indication of the number of tests that are run by TeamCity, for Windows with Java 1.8, 23.709 tests have been passed successfully [11].

In order to verify existing tests manually, the untested code can be introduced in the /subproject folder after which the ./gradlew :<subproject>:check command can be run. During the build Gradle also executes Checkstyle and Codenarc tests that perform static code analysis. The use of PMD throughout the development process is also encouraged.

Finally, simple contributions are only merged into the project when the build succeeds, the tests are all passed and new test material is provided and reviewed to be in good order. Complex changes must face the promotion pipeline, in which they will be tested more thoroughly in different environments and levels to assure quality [23].

The Spock Framework

Gradle uses the Spock Framework as their testing framework of choice. The framework was initiated by Peter Niederwieser who joined the Gradle team in 2011 and remained an active employee until late 2014. Peter received help from Luke Daley who is still part of the core development team of Gradle Inc. Therefore, the Spock Framework is made by a (former) Gradle employee, but can be considered as an independent piece of software used by Gradle in their development process.

The open source project Spock integrates enterprise testing, mocking, stubbing and does this in a behaviour driven way [12]. It covers a diverse spectrum of test types, ranging from unit testing to integration testing and even functional testing. Figure 9 shows the different tools that can be replaced by integrating the Spock framework.

/**
 * Meta-info about a Java component.
 *
 * TODO - this is some legacy stuff, to be merged into other component interfaces
 */
public interface BuildableJavaComponent {
    Collection<String> getRebuildTasks();

    Collection<String> getBuildTasks();

    FileCollection getRuntimeClasspath();

    Configuration getCompileDependencies();
}