Your software should be versioned, and the assigned version numbers should be represented somewhere in your source control management. This plugin detects tags of your source control management matching a given pattern, extracts the version number, and makes it available both to Gradle and optionally your program. It rids you of the nuisance to keep the version number in your scm and the version number for your deployment in sync.
The plugin is fully self-contained, i.e. it does not rely on the availability of any version management binaries on the system.
The plugin is applied as given below:
Gradle 2.1 or later:
plugins {
id 'de.ploing.scmversion' version '0.6.6'
}
Older versions of Gradle:
buildscript {
repositories {
maven {
url 'https://plugins.gradle.org/m2/'
}
}
dependencies {
classpath 'gradle.plugin.de.ploing.gradle:scmversion-gradle-plugin:0.6.6'
}
}
apply plugin: 'de.ploing.scmversion'
In contrast to earlier versions, the scm in use is automatically detected, no more need to have separate plugins for different scms.
Currently, only git is supported. The plugin can be easily extended to new scm systems.
When the plugin is applied, it will replace the version
property of gradle with the one determined from the scm tags:
-
If the current scm state is on a revision with a version tag, and if no files are modified (i.e. the repo is not dirty), the version number from the version tag is used
-
Otherwise, the highest version number from a tag is determined, the least significant number is increased by one and appended by the snapshot suffix
-
If no version tag is found, the version number
0
is assumed
The version property is e.g. used by the maven plugin for determining the version information for assembled jar files.
The task setVersion
is provided for this purpose; it is automatically called after setting up the project.
If a property filename is configured, the plugin will write the current scm status to a property file:
scmversion {
propertyFilename = 'scmversion.properties'
}
The Gradle task createVersionFile
will put a file named scmversion.properties
to the directory build/resources/main
.
The property file may look like the following:
#SCM version information version=1.0.3-SNAPSHOT rev=d460689dd68071442beeee4d984a85f9996d7a37 dirty=false
The format of version tags can be customized using a regular expression; the default looks like the following:
scmversion {
releaseTagPattern = 'version-([0-9.]*)'
}
The regular expression fulfills two purposes:
-
Determine if the tag is a version tag
-
Extract the version number
The matched part will be used as version number; if you choose to use an alternate version number scheme not matching the regex above: Read on :-)
The default configuration handles version number consisting of an arbitrary number of version number parts separated by a dot (e.g. "1.0" or "2.0.3"). If you choose to use a different pattern, you not only have to adapt the `releaseTagPattern`regex, but re-implement the following two closures:
versionComparator
-
A closure taking two version numbers as parameters. It returns -1/0/1 if the first version number is smaller/equal/larger than the second.
incVersion
-
A closure taking one version number as parameter and returns a new version string. The purpose of this closure is to determine the version string used for snapshot versions, i.e. the "next" version after the latest one.
By default, the plugin assumes that the project root equals the scm root. This is true in most standard cases, but a multiproject setup hosted in one scm repository breaks this assumption. If your scm root lies outside your project, you can tell the plugin to search for it above the project root directory:
scmversion {
scmRootSearchDepth = 2
}
The parameter gives the maximum number of directory levels to search for the scm root. The example given above means that the scm root is first expected in the project root; if not found, one directory level above the project root is checked; if still not found, the search ascends another directory level. If no scm is present here, the plugin will throw an error.
The version is set by executing a task after initializing the project. This means that the version variable is not (yet) set to the desired value when using it e.g. in string concatenations. To allow access to the calculated version, the version field is set to a proxy object, which determines the version in its toString method on demand. After project initialization, the proxy object is replaced by a regular string.
Bear in mind that the proxy object can only reflect the current state; this means that the order of your statements is of importance. You have to make sure that this plugin is properly configured before you access the version information.
Copyright 2014 - 2015 by Stefan Schlott
Licensed under the Apache License, Version 2.0.