craftsman: CraftsmanCapabilityBuildLifecycle

Crafstman Module Capabilities

This page describes the category of capabilities supported by Craftsman that are Module Extensions.

build-extension

A build extension is a class, module, or plugin to use for a particular build life-cycle step. by specifying an extension, you can unilaterally alter how the craftsman build file is created or how certain tasks behave.

options:

implementation: The fully qualified class name to use for this build step/functionality.

REQUIRED
valid values:
- any[1]

build-extension-custom-section

extends build-extension

A custom section to add to the build process. These represent life-cycle sections or steps that are not in Craftsman by default.

options:

section: The section name.

REQUIRED
valid values:
- any[1]

header-section-extension

extends build-extension

A custom implementation to use for the "header" of the the Craftsman build process. The header section represents the steps that are not necessarily in the build process, but are always needed or convenient to have in place.

clean-section-extension

extends build-extension

A custom implementation to use for the clean steps of the the Craftsman build process. The clean section represents the steps needed to clean a source tree as a part of a build process. Note: this does not necessarily refer to calls to "clean", but it can. That is, the clean section encompasses the usual "manual clean" step plus any automatic cleans that might be done as a part of the build process (such as if a "force" was called to make sure the module was cleaned automatically).

build-module-section-extension

extends build-extension

A custom implementation to use for the module build steps of the the Craftsman build process. The build module section represents the steps required to compile the module and move its resources to the build destination. This may include custom code generation, compile calls, file copies, and more.

build-test-section-extension

extends build-extension

A custom implementation to use for the test build steps of the the Craftsman build process. The build test section represents the steps required to compile the unit tests and move their resources to the build destination. This may include custom code generation, compile calls, file copies, and more.

test-section-extension

extends build-extension

A custom implementation to use for the unit testing steps of the the Craftsman build process. The test section represents the steps required to unit test the module.

verify-source-section-extension

extends build-extension

A custom implementation to use for the source verification steps of the the Craftsman build process. The verify source section represents the steps required to verify the source and make sure it complies to the standards used by the module or project.

package-section-extension

extends build-extension

A custom implementation to use for the packaging steps of the the Craftsman build process. The package section represents the steps required to produce a complete build artifact from the module (for example, a jar file containing all the classes and resources or a WAR file containing all the Web Application components with a descriptor).

footer-section-extension

extends build-extension

A custom implementation to use for the "footer" of the the Craftsman build process. The footer section represents the steps that are not necessarily in the build process, but are always needed or convenient to have in place. The steps or targets in the footer may or may not be called as a part of the build process.

build-target-extension

An extension of an established build life-cycle target. As opposed to the section extensions, where you must fully implement the section and all of its dependencies yourself, target extensions allow you to hook your own custom tasks, targets, or conditions into the existing implementation.

depends-prepend: Target to place at the beginning of the depends list. This prepends to any standard dependencies created by the implementation itself. Multiple entries are prepended in order they show up in the capability definition. If the definition has a depend-prepend for entry1, entry2, and entry3, the depends list would look like "entry1, entry2, entry3, standardEntryFromImplementation, ...".

multiple entries allowed
valid values:
- any[1]

depends-append: Target to place at the end of the depends list. This appends to any standard dependencies created by the implementation itself. Multiple entries are appended in order they show up in the capability definition. If the definition has a depend-append for entry1, entry2, and entry3, the depends list would look like "..., standardEntryFromImplementation, entry1, entry2, entry3".

multiple entries allowed
valid values:
- any[1]

target-antcall: The name of a target to call from within the task via <antcall>. The module ID is the standard parameter (name "moduleid"), in addition to any parameters or values inherited during the antcall.

multiple entries allowed
valid values:
- any[1]

build-target-extension-with-if

extends build-target-extension

A target extension that supports specifying an "if-condition" for the target.

ifcondition: The name of the condition that must be exist in order to execute the target.

valid values:
- any[1]

build-target-extension-with-unless

extends build-target-extension

A target extension that supports specifying an "unless-conditiion for the target.

unlesscondition: The name of the condition that must not exist in order to execute the target.

valid values:
- any[1]

build-target-extension-with-if-unless

extends build-target-extension-with-if, build-target-extension-with-unless

This is a target extension that inherits from both the if and unless extensions. This means this target (or any children) can have either an if condition, an unless condition, or both.