This document is primarily aimed at build engineers (developers that create and modify the build scripts for a project). However, it contains useful material for any developer that builds a project that uses this plugin and it defines a set of nomenclature around versioning and project release processes that we should all understand. If you are new to gradle, please review the Welcome to Gradle confluence page.
The general semantics of this plugin are controlled by the presence of 2 files:
raptorVersion.txtprojectVersion.txtraptorVersion.txt file controls the version of Raptor being built (or built against, for
project/plugin builds, which are described below).
The projectVersion.txt file, if present, controls the version of the project/plugin being built,
and identifies the build as a "project/plugin build" which
alters the way this plugin prepares the version information. There are two basic types of builds supported
by this plugin: snapshot and release
If only the raptorVersion.txt file exists, then that is the controlling version file. If the
projectVersion.txt file exists, then it is the controlling version file. The version used within
the build is determined from the controlling version file. That version (along with any stage supplied by the
snapshot or release build type, described more fully below) will be applied to any artifacts created by the build.
The term root version refers to the tri-part numeric version without any stage. For example, given a
version string of 2.17.2-RC2, the root version is 2.17.2.
There is one special case, used in the RaptorPlugins project, to ease the burden of managing
these two files to always have the same version. In this case, the project defines the ext property
raptorVersionTracksProjectVersion before applying thus plugin. Given that, only the
projectVersion.txt file is processed and the raptorVersion.txt file doesn't even exists.
Further, the raptorVersion ext property is set equal to projectVersion.
The BuildSupport plugin provides a class, RaptorVersion
that offers easy access to the various parts of a version string (major, minor, patch, and stage components). An
instance of this class is created on each version file found, and those instances are available in the root
project's ext configuration as raptorVersion and projectVersion. Additional properties
are created, see Project Properties Created for a complete list. If you're
unfamiliar with gradle projects and the ext properties extension, try this
search.
The code below shows some example uses of RaptorVersion and the values the various methods return.
// Assume a plugin build (both raptorVersion.txt and projectVersion.txt exist) and those files have
// been read by this plugin, yielding variables raptorVersion and projectVersion
//
// The content of raptorVersion.txt was '2.17.1-RC2'
// The content of projectVersion.txt was '1.2.3-API1' (yes, the 'stage' can be any string we want)
raptorVersion.toString() == '2.17.1-RC2'
raptorVersion.major == 2 // Note these are integer values
raptorVersion.minor == 17
raptorVersion.patch == 1
raptorVersion.stage == 'RC2'
raptorVersion.rootVersion == '2.17.1'
raptorVersion.majorMinor == '2.17'
raptorVersion.asSnapshot() == '2.17.1-SNAPSHOT'
projectVersion.toString() == '1.2.3-API1'
projectVersion.major == 1
projectVersion.minor == 2
projectVersion.patch == 3
projectVersion.stage == 'API1'
projectVersion.rootVersion == '1.2.3'
projectVersion.majorMinor == '1.2'
projectVersion.asSnapshot() == '1.2.3-SNAPSHOT'
SNAPSHOT' appended to the root version in the controlling version file. So, regardless
of the stage found in the controlling version file, the stage at build time will be set to -SNAPSHOT.
For example, if the version file has the value 2.17.2-RC2 and a snapshot build is performed, the
build version is 2.17.2-SNAPSHOT. Note that the content of the version file is not changed,
this is the calculated build version determined at run time.
git status will indicate no changes-Prelease, the build
is performed as a release build. You must further specify whether it is an RC or FINAL release by
including the flag -Prc=<rc> or -Pfinal (but not both). For example:
gradle build -Prelease -Prc=RC1
will initiate an RC release build with the stage set to RC1.
A release build automatically invokes the releaseClean and updateReleaseVersion tasks
before 'build' and invokes tagRelease after the build, finally the artifacts are published to Nexus if
configured. See the Command Line Flags section for complete details on all
available flags to control the build further. See the Tasks Created section for
additional details on the tasks added to the build.
One important aspect of the release build is the update to the controlling version file. Since the build will
use the version string verbatim, the text in the controlling version file must be updated and committed prior
to actually performing the build. This is accomplished by the updateReleaseVersion task. The major,
minor, and patch version components are kept as is, but the stage is set according to the release type specified
via -Pfinal or -Prc. For example, if the current version is 2.6.1-SNAPSHOT
and -Prc=RC2 is specified, the version is updated to 2.6.1-RC2 (also note that this
value is the build version). This change is automatically committed and pushed to the remote repo (you
can control this behavior with the -Pnoexec and/or -Pnopush flags, but you should never
use those unless you are performing tests on a build itself). If the version does not change, then the commit/push
operations are skipped.
If the build completes successfully, The tagRelease task will invoke git to apply a tag to the current
revision.
The tag text will be tag-<build version>. The tag is automatically applied and pushed to
the remote repo.
Finally, after all previous operations are completed successfully, any projects that are configured to publish to
Nexus have the publish task invoked to perform that publication.
raptorVersion.txt file indicates a SNAPSHOT version, the build will fail, and you
will see a warning such as this:
==============================================================================
==============================================================================
You are performing a release build against a SNAPSHOT version of Raptor!
In general, you should NOT do this.
If you didn't intend this, please update the 'raptorVersion.txt' file.
You can override this warning using -PraptorSnapshot
==============================================================================
==============================================================================
You can use the -PraptorSnapshot command line flag to cause the build to continue, but you should be sure
that is what you intend before doing so.
If you are trying to perform a FINAL release (using -Pfinal), and the Raptor version is a SNAPSHOT
version, then the build will fail with an error like this:
You can not create a FINAL release based on a SNAPSHOT Raptor version: <version>-SNAPSHOT
Using -PraptorSnapshot will not prevent this. A FINAL build must be
fully reproducible, and therefore can not be based on a SNAPSHOT version of Raptor.
As of Gradle 5, the public gradle plugin portal is automatically searched for plugins, so no 'buildscript' configuration is required. Simply specify the plugin in the 'plugins' section, like this:
plugins {
id 'gov.raptor.gradle.plugins.build-support' version '0.6.3'
}
dependencyManagement section
in settings.gradle. For example:
pluginManagement {
repositories {
gradlePluginPortal() // Include public Gradle plugin portal
mavenLocal()
}
}
develop as the root branch for development, another branch is used,
typically master. In this case, you'll need to override the default setting for the project.ext.rootBranch
property. This can be done by adding a snippet similar to the following directly after you apply the plugin:
ext.rootBranch = 'master'
This plugin handles both single and multi-project builds, but it is up to the consuming plugin to configure the projects that are to participate in the build. For example, in a typical multi-project build, the sub-projects are the actual plugins and the root project is just a container to organize the build. So, in that case, the root project is responsible for configuring the sub-projects as needed.
To make access to the configuration methods in the plugin extension, a project property buildSupport
is created and is a reference to the
BuildSupportExtension
, allowing for direct method invocations on it.
jcenter()mavenLocal() *optionalmavenCentral()
This repository configuration is automatically applied when any project or sub-project is configured as a 'java'
project, which can be accomplished via
buildSupport.configureStandardPlugin(Project p, boolean toNexus, boolean configureTestAgent = true) or
buildSupport.setupJavaProject(Project p), see below for more details.
The repositories are hosted on 2 primary servers, DI2E and CTI, and on DI2E there are a
number of repository groups in use. However, the URLs needed have standardized patterns which can be leveraged
to make configuration simpler. The Build Support Extension offers a simple DSL for configuring the repositories
required by a build. The style of the DSL is modeled along the lines of the existing repositories
DSL. It's easiest to start with a simple example to show the salient points and then dive into the details.
buildSupport {
repoManagement {
di2eCentral()
di2eRaptorx publish: false
di2ePrivate name: 'RP', publish: true
di2ePrivate name: 'UNSAFE', publish: true, username: 'james', password: 'bond'
}
}
mavenCentral() and jcenter() are
automatically added):
DI2E Central - as a source of artifacts only (nothing ever publishes to DI2E Central)DI2E Raptorx - as a source of artifacts only ('publish: false' indicates not to
configure
publishing)
DI2E repo named 'RP' - A private repo for artifact access and publishingDI2E repo named 'UNSAFE' - A private repo for artifact access and publishing, with specified
credentials
https://nexus.di2e.net/nexus/content/repositories/Private_<name>_Snaphots
https://nexus.di2e.net/nexus/content/repositories/Private_<name>_Releases
The table below lists all the supported configuration (map) parameters for repo definitions. Note that not all repository types support all parameters (and this will be discussed below as all the definition methods are described).
| Parameter | Description |
|---|---|
name |
The name of the repository (if it is configurable) |
publish |
Specify whether this repo should be configured as a publishing destination (if it is supported) This value must be a boolean value, not a String.
|
username |
The user name for repository access, this overrides the standard credentials discovery. |
password |
The password for repository access, this overrides the standard credentials discovery. |
The table below lists all the configuration methods available in this DSL with notes on each. Publishing is supported on all repository types unless noted otherwise.
| Method | Description |
|---|---|
noMavenLocal()
|
Specifies that maven local (the local .m2/repository) should not be configured.
|
google()
|
Adds the google maven repository to the configuration. |
di2eRaptorx(java.util.Map)
|
Adds the DI2E Raptorx public repositories to the configuration. A name parameter is not
supported, and will be ignored if specified.
Dependency URL: Publish URL:
|
di2eCentral(java.util.Map)
|
Adds the standard DI2E central repository to the configuration. A name parameter is not
supported, nor is publishing.
|
di2ePrivate(java.util.Map)
|
Adds a DI2E private repository to the configuration.
Dependency URLs: Publish URL:
|
ctiPublic(java.util.Map)
|
Adds a CTI public repository to the configuration.
Dependency URLs: Publish URL:
|
ctiPrivate(java.util.Map)
|
Adds a CTI private repository to the configuration.
A name parameter is not supported, and will be ignored if specified.
Credentials are only required to publish artifacts. If credentials are not specified when publishing a 401 unauthorized status code will be returned from the server. Developers who do not specify credentials should ensure that the build takes place within the CTI corporate network (or over a properly configured VPN). Dependency URLs: Publish URL:
|
The environment is the initial location searched for credentials is the environment. This supports integration with CI servers where no access to the actual machine is permitted, and thus, the credentials encrypted store for a "user" can't be configured. The variables searched for are of the pattern:
<name>_NEXUS_USERNAME
<name>_NEXUS_PASSWORD
Using the configured repository name (converted to all upper case) as indicated. Since many of the repos on a given
host (DI2E or CTI) will share a common set of credentials, a fallback name is also used if the primary name pattern
isn't found. For DI2E, this fallback is, oddly enough, 'DI2E', and for CTI Public repos, it is 'CTI_PUBLIC'.
For the Raptor repositories, the name used is always 'RAPTORX', with a fallback of 'STL'.
Expanding on the example above, if the variable RP_NEXUS_USERNAME isn't found, a fallback variable
of DI2E_NEXUS_USERNAME will be used.
As discussed elsewhere, this plugin applies another plugin to provide encrypted storage of a users credentials on given machine. If no environment variables are found for a given repository, then the credentials store will be accessed to try and locate appropriate values. As with environment variables, standard patterns are used for the user name and password:
<name>RepoUsername
<name>RepoPassword
Using the configured repository name (converted to all lower case) as indicated. As with environment variables,
fallback names are configured for DI2E, you guessed it, 'di2e', and CTI Public, 'public'.
For di2eRaptorx, the name used is always 'di2eRaptorx', with a fallback of 'di2e'.
In the case where some other form of credentials management needs to be used, the script can configure the
credentials for each repo using the optional username and password configuration
parameters on a repository definition. For example, if environment variables are used, but they don't follow the
pre-configured patterns described above, then the script could do something like the following:
buildSupport {
repoManagement {
di2ePrivate name: 'Special', username: System.getenv('MY_CUSTOM_USERNAME'), password: System.getenv('MY_CUSTOM_PWD')
}
}
The repoManagement DSL also offers several methods for retrieving the repo configurations, which include the resolved credentials. This can be useful if a build script needs to access resources using those credentials, such as pushing up javadocs to Confluence.
Each of the finder methods described below return a RepoConfig object that
has a method, getCredentials(), that provides properties username and
password. All other methods and properties of the RepoConfig object are currently
unpublished and are considered internals that may change at any time.
| Method | Description |
|---|---|
getDi2eRaptorx()
|
Returns the DI2E Raptorx repository configuration. |
getDi2eCentral()
|
Returns the standard DI2E central configuration. |
getDi2ePrivate(String name)
|
Get the DI2E private repository configuration with the given name. |
getCtiPublic(String name)
|
Get the CTI public repository configuration with the given name. |
ctiPrivate(String name)
|
Get the CTI private repository configuration with the given name. |
For example (assuming the configuration in the example above):
def repoConfig = buildSupport.repoManagement.getDi2ePrivate('Special')
def credentials = repoConfig.getCredentials()
def username = credentials.username
def password = credentials.password
To keep things simple, the plugin extension offers a single method that can handle the typical plugin project
configuration:
buildSupport.configureStandardPlugin(Project p, boolean toNexus, boolean configureTestAgent = true)
And unless you have very
specific, and unusual conditions in your plugin, you should use this method to configure your projects.
That method is typically applied to all sub-projects, like this:
subprojects { subProject ->
subProject.with {
buildSupport.configureStandardPlugin(subProject, true) // Apply standard plugin project setup
}
}
BuildSupportExtension.
The table below provides a quick summary of the most relevant methods.
| Method | Function |
|---|---|
buildSupport.configureStandardPlugin(Project p, boolean toNexus, boolean configureTestAgent =
true, String... weaveTestPackages = [])
|
Perform the "standard" configuration for a typical Raptor plugin project. This is equivalent to calling
the following methods:
gov.raptor
packages. If you have code in other packages that are part of your plugin and you need them to be woven by
the AOP processor, then specify those additional packages as the
weaveTestPackages parameter to this method.
|
buildSupport.setupJavaProject(Project p)
|
Configure the given project as a java project, with appropriate plugins, compiler configuration and
publishing after a build.
Plugins applied: 'java' and 'maven-publish'
The Java compiler is configured for source and target compatibility of 1.8, and configured to include debug line numbers (but no local variable table). The build task is configured to be finalized by publish so the produced jar file
is copied into the local maven repo (and Nexus, on release builds if configured) if the build succeeds.
If this is a 'release' build, then the build task is configured to depend on
releaseClean and updateReleaseVersion and finalized by tagRelease.
|
buildSupport.createPluginInstallTask(Project p)
|
Create a task, named install, that will copy the created jar/war artifact(s) into
../RaptorT/Raptor/bin/plugins (by default). If the environment variable
ORG_GRADLE_PROJECT_pluginInstallDir is set, it will provide a value for the pluginInstallDir
project property. This may be overridden if the project defines the variable pluginInstallDir
(e.g., using -PpluginInstallDir on the command line, or setting it in a gradle.properties file)
it will override the default destination directory.
Before the artifact is copied, any prior versions of the artifact are deleted from the plugins directory. This attempts to prevent a common mistake when a plugin version changes, is rebuilt, and the result is two versions of the plugin jar in the plugins directory. The install task is dependent upon the build task so that if tests fail, the
artifact is not copied.
|
buildSupport.configurePublishing(Project p, boolean toNexus = true)
|
Configure a project to publish maven artifacts to the local M2 repo and, optionally, to the Nexus maven
repo. This supports dependency references from RaptorPlugins (or any other project) onto artifacts built
here. The artifacts are published to the appropriate release or snapshot repository for each repo configured
with "publish: true" in the repoManagement section using the credentials configured for that
repo.
Publishing to Nexus is only enabled when performing a "release" build (when -Prelease is
specified on the command line), or when -PforcePublish is specified on the command line.
Publishing is disabled if this is a snapshot build ( isSnapshot is true) or
a rebuild (-PrebuildRelease is specified).
If any tests failed during the build, then publishing will be skipped to avoid publication of potentially broken artifacts. |
buildSupport.publishArtifact(Project p, artifactToPublish, boolean toNexus = true)
|
Configure a project to publish a specific artifact (as opposed to a standard component).
See configurePublishing above for all the details of exactly when artifacts are published.
|
buildSupport.configureJavadocPublishing(Project p)
|
Configure a project to create and publish a javadoc artifact (a jar file with a 'javadoc'
classifier'). This method will create a task named packageJavadoc and updates the publishing
configuration (mavenJava) to publish that new artifact. The packageJavadoc task is
only enabled if the javadoc task is enabled. It is up to the consuming build script to
configure the javadoc task as needed.
|
buildSupport.configureSourcePublishing(Project p, boolean mavenLocalOnly = true)
|
Configure a project to create and publish a "sources" jar. By default sources will only publish to maven
local. If you really want sources published to a "real" maven repository, then pass false for
mavenLocalOnly (which defaults to true).
Be certain you understand the access controls of your project before you even consider publishing sources anywhere other than maven local. This method creates a sourcesJar task to produce the jar containing the sources, and creates a
publication named 'sources' that uses the sourcesJar output as the artifact to
publish with a 'sources' classifier.
|
buildSupport.configurePublications(Project p, Closure configClosure)
|
Apply a configuration closure to the publications managed/created by this plugin. A typical use is to
add an artifact to the publications, like this:
mavenJava and forMavenLocal
publications.
|
buildSupport.configureManifest(Project p)
|
Configure a project's jar and war tasks manifest attributes. |
buildSupport.configureManifestForArchiveTask(Jar jar)
|
Configure a given task's manifest attributes. |
buildSupport.configureJavaTemplates(Project p)
|
Configure a project to use "java templates." The templates are assumed to live in
src/main/java-templates, which can be overridden with the javaTemplatesDir project
property.
The generated code will be placed in build/generated-sources, which will be configured as a
java source dir during compilation. The template(s) will be copied using normal gradle token expansion.
The current project will be automatically added to the token expansion map under the name 'project'
and additional tokens can be supplied via the project property templateProperties, which must
be a map of String keys to arbitrary values.
The consuming build script can define the following properties to configure the build:
copyJavaTemplates task and configures compileJava to
depend on it.
|
buildSupport.configureXjc(Project p)
|
Configure the given project for using XJC to compile XML schemas. The invoking project will use the
following optional properties to configure this operation:
*.xjb files), if any, are in the same directory as
the schemas.
|
buildSupport.configureRdmFacades(Project p)
|
Configure the given project for generating RDM facade classes from Structure XML definitions. This adds an extension, of type GenerateRdmFacadesExtension to the project. See the documentation there to get details and examples of how to configure facade generation. |
buildSupport.verifyTreeIsClean()
|
Validate the current working tree is clean (no uncommitted changes). If the tree is not clean a
GradleException
is thrown. This can be overridden by specifying '-Pforce'
|
These methods would be called from within a (sub-)project's build script as needed. For example, here's a complete sub-project build script that configures the use of java templates (which supports code generation using data available to the build, like the current version number).
description = 'My Cool sub-project'
ext {
templateProperties = ['BuildDate': new Date().format('yyyy-MM-dd')]
}
buildSupport.configureJavaTemplates(project)
Now, any java template found in src/main/java-templates (the default) can use the expansion token
${BuildDate} and it will be replaced with the date of the build.
| Task | Function |
|---|---|
releaseClean |
Clean all build artifacts and prepare for a release build. This task is configured to depend on the
standard clean task and may be configured to perform additional cleanup as needed. This task is
automatically added to the start of the build for any 'release' build (-Prelease or -PrebuildRelease)
|
updateReleaseVersion |
Update the version file according to the current build parameters. The major, minor, and patch components
are unaffected, but the stage is set according to whether -Pfinal or -Prc were
specified. For example, if the current version is 2.6.1-SNAPSHOT and -Prc=RC2 is
specified, the version is updated to 2.6.1-RC2. This change is automatically committed and
pushed to the remote repo. If the version does not change, then the commit/push operations are
skipped.For release builds, this task is configured to run prior to any build operations (and after the releaseClean).
|
tagRelease |
Tag the repo according to the current release build parameters (i.e., -Pfinal or
-Prc).The tag for RC releases is constructed as 'tag-<version>-<RCn>'
(e.g., 2.6.1 with -Prc=RC2 -> tag-2.6.1-RC2).The tag for a final build is just the base version number (e.g., 2.6.1).For release builds, this task is automatically configured to run after the build task
completes, so if the build fails for any reason, the tag is not created.
You can completely override the determination of the tag using -Ptag=<tagString>,
in which case the tag applied will be tagString (note, no 'tag-' prefix).
|
branchRepo |
Create a release branch off the root branch for this repository (typically the dev
branch). The name of the branch is determined from the controlling version, using the major and minor
values. For example, if the controlling version is '2.6.1-SNAPSHOT', the branch created will be
named '2.6'. You can override this name using -Pbranch=<branchName>.
|
rollPatchVersion |
Update the version file by incrementing the patch component and resetting the stage to SNAPSHOT
(e.g., 2.6.1 -> 2.6.2-SNAPSHOT)
|
rollMinorVersion |
Update the version file by incrementing the minor component and resetting the stage to SNAPSHOT
(e.g., 2.6.1 -> 2.7.1-SNAPSHOT)
|
| Flag | Affect on Operation |
|---|---|
-PnoMavenLocal |
Exclude mavenLocal() from the configured build repositories and prevent publication of
artifacts to maven local.
|
-Prelease |
When performing a build, indicate that it is a release build. A release build automatically
invokes the releaseClean and updateReleaseVersion tasks before 'build' and invokes
tagRelease after the build, finally the artifacts are published to Nexus if configured. When
-Prelease is specified, you must also specify one of -Pfinal or -Prc,
but not both.
|
-Pfinal |
When performing a release build or updateReleaseVersion, indicate that it is a
final build
|
-Prc=<rc> |
When performing a release build or updateReleaseVersion, indicate that it is an RC
build, example -Prc=RC1 |
-PraptorSnapshot |
Force a release build of a plugin project even if the raptorVersion.txt file specifies a
SNAPSHOT version. For any non-final release build, it is generally a bad idea to build against a Raptor
SNAPSHOT, but it is necessary in some cases. Without this flag, this plugin will issue a warning and
terminate the build in that situation. Note that in no case is it allowed to perform a FINAL release
build against a SNAPSHOT Raptor version.
|
-PrebuildRelease |
When performing a build, indicate that it is a rebuild of a prior release build. The version
used will be exactly what is in the version file and NO publishing to Nexus will occur.
|
-Ptag=<tag> |
Used with the tagRelease task to fully specify the tag to be applied, see the
tagRelease task description above
|
-PpluginInstallDir |
Used with the install task to control the directory into which plugin artifacts are copied. The
default is '../RaptorT/Raptor/bin/plugins' (relative to the root project being processed). If
the environment variable ORG_GRADLE_PROJECT_pluginInstallDir is set, it will provide a value
for the pluginInstallDir project property.
|
-PforcePublish |
When performing a non-release build, force the publication of artifacts to Nexus |
-Pforce |
When performing any operation that validates expected state and would normally halt the build, force the check to be ignored and continue the build - USE WITH CAUTION |
-Pnoexec |
(Test Support) When performing any git operations, do not actually execute the command, just report it |
-Pnopush |
(Test Support) When performing any git operations that would push commits to the remote, do not actually perform the push |
-PuseTestRepo |
(Test Support) Configure the build to publish to build/repo instead of to Nexus |
-PsafeTest |
(Test Support) Equivalent to -Pnoexec -Pnopush -PuseTestRepo -Pforce |
-PdumpCredentials |
(Debug Support) If specified, the credentials for each configured repository (via repoManagement) are displayed. USE WITH CARE since this will display your password. |
The following variables are defined:
| Variable | Value |
|---|---|
rootBranch |
Set by the consuming script to specify the name of the root branch for this repo. This branch is
used as the basis for creating release branches with the branchRepo task. It has a default
value of dev.
|
installBothWarAndJar |
Set by the consuming script if it produces both a jar and a war and it wants to install both of them.
There are problems when a 'war' project is a dependency of another project. In this case when the dependent project is built, the war project is build as a dependency, but gradle builds a jar (that would not normally be created when doing a 'build' in that project directly). That would lead to having both a jar and a war being installed into the plugins directory when only a war should have been copied. In order to handle this case, this configuration parameter can be used to control this behavior. If a plugin project's build would generate both a jar and a war and both should be installed, the ext variable installBothWarAndJar must be defined.
|
grgit |
Grgit instance opened on the rootProject directory |
os |
The org.gradle.internal.os.OperatingSystem under which this build is being performed |
osFamily |
The OS family under which this build is being performed: windows, linux, or macosx
|
nativeLibPath |
The native library path to use according to the current os |
jvmBitSize |
The architecture bit size: 32 or 64 |
runningUnderJenkins |
Boolean value, true if this build was initiated by the Jenkins CI server |
testFailureCount |
Total number of failed tests during this build (used to control publication of artifacts) |
raptorVersionFile |
A File object referencing the raptorVersion.txt file |
raptorVersion |
The RaptorVersion object created from the content of raptorVersionFile |
projectVersionFile |
A File object referencing the projectVersion.txt file |
projectVersion |
The RaptorVersion object created from the content of projectVersionFile, if it
exists
|
baseVersion |
String value of raptorVersion (or projectVersion, if defined), e.g., 2.7.1-API
|
rootVersion |
String value of raptorVersion (or projectVersion, if defined) minus the stage,
e.g., 2.7.1
|
buildVersion |
String value of derived version being built, isRelease ? baseVersion : baseVersion.asSnapshot()
|
versionFile |
File, The controlling version file, if this is a project build, then
projectVersionFile else raptorVersionFile |
isRebuildRelease |
Boolean value, true if -PrebuildRelease is specified on the command line |
isRelease |
Boolean value, true if -Prelease is specified on the command line or
isRebuildRelease is true
|
forceSnapshot |
Boolean value, true if -PraptorSnapshot is specified on the command line |
isSnapshot |
Boolean value, true if this is a snapshot build, determined by !isRelease ||
baseVersion.isSnapshot() |
isProjectBuild |
Boolean value, true if this is a build of the RaptorT project, false if this is a project-level build |
force |
Boolean value, enabled with -Pforce, if true, force past any validation that would typically
halt the build, USE WITH CAUTION!
|
noExec |
Boolean value, enabled with -Pnoexec, if true, do not actually execute any GIT operations (like
tag), just print what would be done
|
noPush |
Boolean value, enabled with -Pnopush, if true, do not perform a 'git push' on any GIT
commits/tags made locally
|
isForcePublish |
Boolean value, enabled with -PforcePublish, if true, force publication to external repo even if
this is a snapshot build
|
raptorVersion.txt file is presentpublishToMavenLocal tasks when running under jenkins or when
-PnoMavenLocal is specified
showStandardStreams = true in the test configuration by defaulttestFailureCount, to track test failuresmavenLocal() repo usage if running under jenkins