Search Gradle plugins

javamuc.gradle-semantic-build-versioning

This is a Gradle settings-plugin that provides support for semantic versioning of builds. It is quite easy to use and extremely configurable. The plugin allows you to bump the major, minor, patch or pre-release version based on the latest version, which is identified from a git tag. It also allows you to bump pre-release versions based on a scheme that you define. The version can be bumped by using version-component-specific project properties or can be bumped automatically based on the contents of a commit message. If no manual bumping is done via commit message or project property, the plugin will increment the version-component with the lowest precedence; this is usually the patch version, but can be the pre-release version if the latest version is a pre-release one. The plugin does its best to ensure that you do not accidentally violate semver rules while generating your versions; in cases where this might happen the plugin forces you to be explicit about violating these rules. As this is a settings plugin, it is applied to settings.gradle and version calculation is therefore performed right at the start of the build, before any projects are configured. This means that the project version is immediately available (almost as if it were set explicitly - which it effectively is), and will never change during the build (barring some other, external task that attempts to modify the version during the build). While the build is running, tagging or changing the project properties will not influence the version that was calculated at the start of the build.

https://github.com/javamuc/gradle-semantic-build-versioning

Version 4.1.1 (latest)

Created 26 July 2018.

This project is a fork of the Semantic versioning for Gradle plugin by vivin. This version of the plugin adds the option to tag the same commit several times with a new version.

Build script snippet for plugins DSL for Gradle 2.1 and later:

plugins {
  id "javamuc.gradle-semantic-build-versioning" version "4.1.1"
}

Build script snippet for use in older Gradle versions or where dynamic configuration is required:

buildscript {
  repositories {
    maven {
      url "https://plugins.gradle.org/m2/"
    }
  }
  dependencies {
    classpath "gradle.plugin.javamuc:gradle-semantic-build-versioning:4.1.1"
  }
}

apply plugin: "javamuc.gradle-semantic-build-versioning"

Build script snippet for plugins DSL for Gradle 2.1 and later:

plugins {
  id("javamuc.gradle-semantic-build-versioning") version "4.1.1"
}

Build script snippet for use in older Gradle versions or where dynamic configuration is required:

buildscript {
  repositories {
    maven {
      url = uri("https://plugins.gradle.org/m2/")
    }
  }
  dependencies {
    classpath("gradle.plugin.javamuc:gradle-semantic-build-versioning:4.1.1")
  }
}

apply(plugin = "javamuc.gradle-semantic-build-versioning")

Why?

The new way to add plugins to a project is much more than a more convenient syntax. The new DSL is processed very differently to the old one. The new mechanism allows Gradle to determine the plugins in use very early and very quickly. This allows Gradle to do smart things such as:

  • Optimize the loading and reuse of plugin classes.
  • Allow different plugins to use different versions of dependencies.
  • Provide editors detailed information about the potential properties and values in the buildscript for editing assistance.

This requires that plugins be specified in a way that Gradle can easily and quickly extract, before executing the rest of the build script. It also requires that the definition of plugins to use be somewhat static.

There are some key differences between the new plugin mechanism and the “traditional” apply() method mechanism. There are also some constraints, some of which are temporary limitations while the mechanism is still being developed and some are inherent to the new approach.

Constrained syntax.

The new plugins {} block does not support arbitrary Groovy code. It is constrained, in order to be idempotent (produce the same result every time) and side effect free (safe for Gradle to execute at any time).

The form is:

plugins {
    id «plugin id» version «plugin version»
}

Where «plugin version» and «plugin id» must be constant, literal, strings. No other statements are allowed; their presence will cause a compilation error.

The plugins {} block must also be a top level statement in the buildscript. It cannot be nested inside another construct (e.g. an if-statement or for-loop).

Can only be used in build scripts.

The plugins {} block can currently only be used in a project's build script. It cannot be used in script plugins, the settings.gradle file or init scripts.

Future versions of Gradle will remove this restriction.

Cannot be used in conjunction with subprojects {}, allprojects {} etc.

It is not possible to use the familiar pattern of applying a plugin to multiple projects at once using subprojects {} etc. at the moment. There is currently no mechanism for applying a plugin to multiple projects at once. At the moment, each project that requires a plugin must declare so in the plugins {} block in its buildscript.

Future versions of Gradle will remove this restriction.

If the current limitations of the new plugin mechanism are problematic for your build, the recommended approach is to use the “traditional” mechanism for the time being.