The objective of this tutorial is to demonstrate the usage of the -version option when building multiple projects.
By default the build system assigns the version identifier of SNAPSHOT.
We can override this using the -version commandline option. In the following example we are requesting a listing of the in-scope projects together with the version cli option. The resulting list is the list of projects that would be build if we dropped to list option.
$ build -list -version ABC Selection: [3] [1] project:org/acme/plugin/clock-api#ABC [2] project:org/acme/plugin/clock-impl#ABC [3] module:org/acme/plugin#ABC $
A generalized version applies to a complete module is sometimes not sufficient to properly describe the desired results of a multi-p[roject build in terms of version naming requirements. For example, by applying the generic -version cli option we are stating that all resources defined withing the module (without an explicit version declaration) shall be produced with version XYZ. A more realistic scenario is that your top-level index versioning strategy could reflect a public XML specification whereas internal project version could reflect API based version evolution. In these scenarios it is useful to include a specification prefix - for example the version identifier "1.0.0-RC3" could be expressed as a decimal prefix of "1.0.0" and a version suffix of "RC3". Depot enables this strategy through the following properties:
project.version-prefix.enabled | If true then the version value generated for a given project will be derived from the values of the major, minor and micro project version attributes described below. |
project.major.version | The major version prefix value (must be an integer). |
project.minor.version | The minor version prefix value (must be an integer). |
project.micro.version | The minor version prefix value (must be an integer). Typically used to represent a sequential publication value. |
In version prefixing is enabled (typicically via a high-level module property defintion) and major, minor and micro versions are assigned within respective modules and projects (reflecting respective development lifecycles), then the resulting version assigned to a project artifacts will correspond to the the following convention:
[major].[minor].[micro]-[cli-supplied-version-argument]
The DPML project artifacts use the following convention:
major | All resources sharing the same major version are deemed as backward compatible. |
minor | A minor version represents a functional extension or enhancement that is compatible within the context of the major version identifier. |
micro | A micro version represents a sequential release identifier relative to the [major].[minor] namespace. |
The above sequence demonstrates the impact of the -version option in terms of resource naming and the corresponding meta-data (such as module information) that is generated by the build process. All of the resources (jars, module files, etc.) are now suitable for publication into a public (or shared) repository.