This page lists the components of the Holy Gradle software, with links to more details on each part. Below is a diagram showing how these pieces fit together; this is an expanded version of the one on the Overview page.

Figure 1: gloss:Holy Gradle component dependencies

Custom Gradle Distribution

See the custom-gradle for details of the Holy Gradle custom distribution.

Custom Plugins

Actively Maintained

Custom Gradle Core

The custom-gradle-core-plugin is used by most of the other gloss:holygradle plugins.

This plugin supports the following.

  • Some useful standard tasks.

  • prerequisites syntax to help you specify prerequisites for difficult cases where a dependency can’t be simply unzipped into a folder and must be manually installed, e.g., Microsoft Visual Studio.

My Credentials

The my-credentials-plugin supports the following.

  • Securely storing credentials using the Windows Credential Manager, and using them in a build.gradle script.

  • Displaying a dialog box to request credentials from the user.

    • Time-out to prevent the dialog box from causing an automated build to hang.

Intrepid

The intrepid-plugin supports the following.

  • Configurations

    • Create sets of related configurations following standard patterns.

  • Source code dependencies

    • Retrieving source code repositories from Subversion, Mercurial or Git.

    • Caching Subversion and Mercurial credentials in the Windows Credential Manager.

    • Specifying dependency metadata when publishing a module with its source code dependencies.

    • Overriding a source code dependency and using already-published versions of that module instead.

  • Packed dependencies

    • Retrieving dependencies which are ZIP files and unpacking them into your workspace.

    • Unzipping to a per-user cache and creating a link to there from your workspace, to save space when multiple workspaces have the same dependencies.

    • Explicit creation of extra directory links within workspace if required.

    • Control of folder naming to allow multiple versions of the same component.

    • Overriding a packed dependency to use an existing source project on disk instead.

  • Publishing

    • Creating "packaged artifacts" (that is, ZIP files).

    • Uploading to Ivy format repository.

Artifactory Manager

The artifactory-manager-plugin supports the following.

  • Deleting artifacts from an Artifactory server according to rules such as:

    • delete anything older than X days/weeks/months; or

    • delete anything older than Y days/weeks/months but keep one version per day/week/month.

Minimal Maintenance

DevEnv

Note
This plugin is not actively maintained.

The devenv-plugin supports the following.

  • Invoking DevEnv to build and clean a Visual Studio solution.

  • Building each module only once, even if multiple other source modules depend on it.

  • Specifying a solution file.

  • Specifying which version of DevEnv to use.

Unit-Test

Note
This plugin is not actively maintained.

The unit-test-plugin supports the following.

  • Syntax for defining your unit test processes.

  • Automatically creating tasks to run your unit test processes.

  • In a multi-module build, running tests in order according module dependencies, or running them for one project independently.

  • Syntax to define unit test flavours, defaulting to Debug and Release.

    • Automatically replacing strings <flavour> and <f> in test definitions.

Stamper

Warning
This plugin is not actively maintained and is unlikely to be supported. We recommend you do not use it.

The plugin-stamper.html supports the following.

  • Stamping information (such as version numbers) into text files.

  • Syntax for defining which files to stamp and how to stamp them (using regular expressions).

How Tasks Are Run

This is a rough explanation of what happens in Gradle and Holy Gradle plugins when you run a simple task such as gw tasks.

  1. gw.bat is executed and it tries to determine which version of Java to use. If it can’t find a suitable version of Java then it will fail. If it can, then it uses Java to run the gradle wrapper jar file, gradle/gradle-wrapper.jar.

  2. The Gradle Wrapper does some bootstrapping to ensure that Gradle is on your machine.

    1. If the optional file gradle/base-url-lookup.txt is present and contains a line for the DNS suffix of the machine, that value is used to initialise HOLY_GRADLE_REPOSITORY_BASE_URL; otherwise the user must set it manually.

    2. If the optional folder gradle/certs exists, the Java keytool.exe will be used to combine all SSL certificate files in that folder with the Java built-in ones in JRE/lib/security/cacerts , and the combined "trust store" file will be passed to the Gradle process. This allows it to access servers which use self-signed root certificates.

    3. The file gradle/distributionPath.txt contains a URL path to a specific custom-gradle version. gw.bat combines this with the value in HOLY_GRADLE_REPOSITORY_BASE_URL and gradle/gradle-wrapper.properties.in to create the file gradle/gradle-wrapper.properties. If you haven’t previously used this distribution then the Gradle Wrapper will download it from this URL to your Gradle user home directory. It will display lots of dots while it does this.

  3. The Gradle Wrapper calls on to Gradle to run the requested task.

  4. Gradle will use the current working directory to determine which project(s) should be evaluated. If you’re using a stand-alone project then Gradle will simply identify build.gradle as your build script. If you’re using a multi-project workspace then it’s more complicated and depends on settings.gradle files.

  5. Properties will be evaluated. These come from gradle.properties files which can live in a number of locations. See link here.

  6. Next, Gradle will look for any settings.gradle scripts. These scripts do not contain configuration of individual projects but allow you to describe which projects to be included. This allows for multi-project workspaces.

  7. Now, for for each project in your multi-project workspace:

    1. Assuming that you’re using a custom-gradle distribution from the Holy Gradle then the distribution will contain an init script. This is called holy-gradle-init.gradle and can be found by running the task openInitScript. At this stage Gradle will invoke all init scripts. In the case of Holy Gradle, this results in the gplugins extension being registered.

    2. Gradle will evaluate the buildscript block first. This is used for defining the dependencies of the buildscript itself; for example, repositories containing plugins, version numbers for plugins, and so on. The gplugins extension is a helper to allow you to briefly define the version numbers of plugins that you want to use.

    3. When gplugins.apply() is called, all of the plugins you have previously specified will be applied. This invokes logic in each of the plugins, which typically adds further extensions and tasks. For example, the intrepid-plugin would add packageArtifacts and other extensions.

    4. Now the build script itself is evaluated, and all of the extensions defined in plugins are available for use. This typically adds lots of configuration, but doesn’t do very much. For example the packageArtifacts extension might now have some packages defined, but there would not yet be any tasks to do the packaging.

    5. After the build script is evaluated Gradle will invoke any closures that have previously been registered using project.gradle.projectsEvaluated or project.afterEvaluate. Many of the Holy Gradle plugins use this mechanism in order to defer execution of logic until after the build script is evaluated. For example, at this stage the intrepid plugin can now iterate over all the packages that the build script configured in the packageArtifacts extension and configure tasks.

  8. At this stage all plugins have been applied, all project build scripts have been evaluated and all plugins have completed their "after evaluated" closures. Gradle now has a complete set of tasks and can now look at the original request gw task and try to invoke a task. In this case, Gradle has defined a task named tasks and since task is an unambiguous abbreviation, the tasks task is selected to be run.

  9. Gradle now invokes the task, first invoking any doFirst closures and then invoking doLast closures.

DONE: https://bitbucket.org/nm2501/holy-gradle-plugins/wiki/HolyGradleCookbook#!what-actually-happens-when-i-run-a-simple-task-like-gw-task