Glossary

In Gradle terms, an artifact is one of the files contained in a module, apart from the metadata file. The phrases "download/fetch a module" or "upload/publish a module", really refer to transferring the artifacts (and metadata file) of the module.

A web service product which manages collections (repositories) of pre-built software modules. It is a commercial product from http://www.jfrog.com which has both a free, open source version and a paid version with more features. The Holy Gradle can work with either version.

This is a Windows program which stores a list of usernames and passwords, encrypted so that only the current user can access them.

In this documentation, build management means controlling how input forms of software (like C++ source files) are converted to output forms (like DLLs or EXEs). This usually means using a tool like Unix make, Microsoft’s MSBuild, or the Ant tool for Java—or Gradle. The Holy Gradle does not use Gradle's build management to control the details of building a Visual Studio solution, because Visual Studio already does that. It only uses it to connect the tasks involved in getting and publishing modules.

A type of object found in many programming languages. It is an anonymous function which contains ("is closed over") references to values and variables from outside its definition. Groovy programmers use closures in creating DSLs. Closures also exist in C++11, Java, Python, and many other languages.

A configuration is Gradle concept meaning a "part" or "slice" of a module which can be used separately from other parts. Each configuration in a module has its own dependencies, and its own collection of artifacts.

A configuration set is a Holy Gradle concept: an object which creates and references a number of configurations which are related in some way. For example, unlike JVM-based code, native applications often vary by platform, build setup (Debug or Release), etc.--as reflected in the C/C++ "model" in newer versions of Gradle—and it is natural to map these to separate Gradle configurations. The configuration set type of the configuration set determines the relationships within and across modules, and partly determines their names. The configuration set itself may modify the names so that a module can contain more than one configuration set of the same type—for example, if a single module packages matched client and server libraries.

A configuration set type is a Holy Gradle concept: an object which defines a specific set of relationships between configurations in a configuration set, defines how to map them to corresponding configurations in another module, and includes some kind of template or pattern for naming them.

Some software module B is said to be a dependency of module A if A needs ("depends on") B in some way. Module B might be needed only when building A, or it might be needed to build other modules which depend on A, or it might be needed at runtime, and so on. In Gradle, dependencies are not directly between modules, but between configurations of a module. When fetching dependencies, Gradle will download the metadata for each module, then use that to identify which artifacts belong to which configurations, and download those files. In the Holy Gradle, package artifacts are also automatically unzipped into the Gradle user home area.

See dependency.

Managing information and tasks related to software modules which depend on each other. In the context of Gradle and Artifactory, module metadata includes the name of the module and its publisher (group), the version of the module, and a list of dependencies on other modules. The most basic tasks are: getting all dependencies for a module you want to build; and publishing that module with metadata, after it is built.

A directory junction is a type of filesystem link in Windows. Specifically it is a kind of NTFS reparse point which acts as an alias to a directory. Unlike symbolic links, a directory junction can only point to a directory, not to a file. However, it can be created without Administrator privileges on Windows 8 and above. Deleting a directory junction does not delete the target directory. See also hard link, link, symbolic link.

A programming language designed for a specific, focused topic (domain). The flexible syntax of Groovy makes it easy to add domain-specific syntax to the language, so that code for a narrow topic can also use the full programming language, plus any Java libraries. The most common kinds of syntax extension in Groovy are (a) a new type of block, which looks like a built-in block structure (like if { ... }) but is really a function call taking a closure as an argument; and (b) implicit properties, where an identifier is treated as a reference to an object property, and that property is created dynamically. For example,

configurations {
    build
}

configurations({ ConfigurationHandler c ->
    c.build; // creates new Configuration and assigns it to new property "build"
});

See domain-specific language.

A distributed version control system: see https://git-scm.com/. The Holy Gradle has support for cloning repositories from a Git repository, including it in your Gradle build automatically, and recording the source version with your module when publishing it.

An open source tool for dependency management and build management. Here "dependency management" means getting and publishing versioned software modules, mostly binary: Gradle modules components which your project uses, modules which those modules use, and so on; and it automatically finds version conflicts. The "build management" part is similar to systems like Unix make, Microsoft’s MSBuild, or the Ant tool for Java: you describe tasks and connections between them, and Gradle works out which tasks to run, in which order. Currently the Holy Gradle is based on Gradle 1.4, which is based on Groovy 1.8.8.

To reduce start-up time, Gradle can be run in a mode where a background process (daemon) stays running and each build you run is passed to that process. The Holy Gradle turns this option on by default, but you can turn it off. See The Gradle Daemon for more information.

Gradle can be downloaded from http://www.gradle.org/ but also allows organisations to use their own local, customised distributions which can include configuration specific to the organisation, for example, special init scripts.

A folder where Gradle caches downloaded files. This is defined by the GRADLE_USER_HOME environment variable or, if that is undefined, it defaults to %USERPROFILE%\\.gradle. The Holy Gradle also caches unpacked files from packages in this area. Files are not automatically deleted from this area, so you must clean it out yourself occasionally.

A small set of files which lets you use a specific distribution of Gradle for building a project, without installing Gradle globally on your machine. It includes a batch file, a small Java JAR file, and some configuration files. Normally it is checked in to your project's source repository. The Holy Gradle uses a custom Gradle Wrapper which downloads a custom distribution of Gradle.

Groovy is a scripting language based on the Java Virtual Machine (JVM). It is used as the basis for Gradle because it is easy to add new syntax to the language, for specific purposes. Gradle adds syntax related to building code by running tasks. The Holy Gradle extends the Gradle syntax. See http://www.groovy-lang.org/ for more information on Groovy, but note that it only documents the latest version. Currently the Holy Gradle is based on Gradle 1.4, which is based on Groovy 1.8.8 (an older version).

A hard link is a special file which contains a reference to another file object on disk. It can only link to a file, not to a directory. It works like a reference-counting pointer in C++, or a reference in .NET or Java: deleting the file from its original location will not completely delete it, if one or more hard links still exist. Unlink a symbolic link, deleting a hard link may delete the original file, if it is the last link. The target file must be on the same volume, and must exist when the link is created. Like directory junctions and unlike symlinks, hard links do not require any special Administrator privileges to create[]. See also directory junction, link, and symbolic link.

A set of Gradle plugins which extend it to cover: using passwords stored in the Windows Credential Manager; getting source code from Git, Mercurial or gloss-subversion[]; getting and publishing dependencies with many files (packed as ZIP files); and deleting temporary publications from Artifactory. There are other features with minimal support: building with Visual Studio; running unit tests. Currently the Holy Gradle is based on Gradle 1.4.

A Gradle init script is a .gradle script which is run before your build. Such a script can be passed on the command line but usually is packed up as part of a Gradle distribution. See http://www.gradle.org/docs/1.4/userguide/userguide_single.html#init_scripts for more detail. The Holy Gradle init script can be seen by running gw openInitScript.

A dependency management tool written in Java, which works stand-alone or with Apache Ant. Gradle shares many concepts with Ivy, and produces the same ivy.xml files to describe the modules it publishes.

The standard filename for the metadata file used by the Ivy tool, which Gradle can also use. This term is also used to refer to the Ivy XML file format.

Software to run a continuous integration (or "auto-build") service on a server. These services run tasks periodically, mainly to check that source code can be built and passes tests. See http://jenkins-ci.org/ for more information.

Parts of the Holy Gradle will create a directory junction if possible, or a symbolic link if not (for example, if the target is on a network share).

A distributed version control system: see http://mercurial.selenic.com/. The Holy Gradle has support for cloning repositories from a Mercurial repository, including it in your Gradle build automatically, and recording the source version with your module when publishing it.

Gradle, Artifactory, and Ivy use the word "metadata" for the information which describes a module: mainly, its identifier, configurations, artifacts, and dependencies. The Holy Gradle uses ivy.xml files, though other file formats exist, and sometimes the metadata can be implicit.

This is a Holy Gradle term for a package which is intended to perform operations on other packages/modules. Typically the meta-package contains a build.gradle file which uses the Holy Gradle plugins, plus other Gradle features, for tasks such as downloading all the transitive dependencies of a module and creating a ".zip" file containing the module plus its dependencies.

In the context of the Gradle, Ivy and Artifactory tools, a module is a piece of software identified and packaged in a specific way. A module is identified by three string values:

A Holy Gradle term which means "an artifact which is a ZIP file, to be unpacked after it is downloaded".

The Holy Gradle uses this term to describe modules in which the artifacts are all packages. When such a module is fetched, its artifacts are all automatically unzipped into a common folder, and a link to that folder is created in the workspace.

See packed dependency.

Gradle uses the term project to refer to a build.gradle control file, which defines (among other things) the dependencies required to build the software module, and the information required to publish it. (Artifactory does not use the term project.)

See repository.

This term is often abbreviated as "repo".

A root certificate is part of a cryptographic signed certificate system such as that used by HTTPS. It is an unsigned or self-signed certificate which identifies an authority which you can choose to trust. Certificates can be used to sign other certificates, creating a chain of trust. Operating systems and browsers usually have a built-in list of trusted authorities. See https://en.wikipedia.org/wiki/Root_certificate for more information.

A Gradle file called settings.gradle which read before your build script. This script is normally in the same folder as your build script. See http://www.gradle.org/docs/1.4/userguide/userguide_single.html#sec:settings_file for more detail. When using the intrepid-plugin, part this file is generated for you, to add sub-projects based on source dependencies.

The Holy Gradle allows projects to have dependencies which are built from source in other repositories, using the standard Gradle multi-project build approach. The source code is fetched along with packed dependencies, and those dependency projects are published when the depending project is published, with dependency information automatically inserted into the ivy.xml.

See source dependency.

A centralised version control system: see https://subversion.apache.org/. The Holy Gradle has support for cloning repositories from a Subversion repository, including it in your Gradle build automatically, and recording the source version with your module when publishing it.

A symbolic link is a special file which contains a reference to another file path. Attempts to read or write the link will access the target file; deleting the link will only delete the link. The target file may be on any disk, and may not exist, in which case attempts to access it will fail. Windows supports symbolic links since Windows Vista (and Windows Server 2008). If a user is a local administrator, they must disable User Account Control to be able to create symbolic links. Under Windows 8 and above, they must additionally run Gradle with Administrator privileges. See also hard link, directory junction.

See symbolic link.

Because software often changes over time, there may be many versions of each module. Therefore a reference to a dependency module must include the version. Each version may add or remove dependencies of its own, or change their versions. If the same module is used in more than one place in the dependency graph with different versions, Gradle normally picks the "newest" one. For safety, the Holy Gradle by default raises an error if there is any conflict, because it is intended for use with C++ libraries, and it is not as easy to replace versions of a library in C++ as in Java. Note that, although the version may look like "1.2.3" it is just treated as a string, to determine which is newer — so, for example, "1.2.11" is less/older than "1.2.3". Therefore we recommend always specifying exact versions.

An informal term meaning the folder hierarchy where a module is built from source. Usually some of the files in a workspace will be checked in to source control, and the rest will be produced by building and running the module. In Gradle terms it is "(the file tree under) the project directory of the root project".

See Gradle wrapper.