WildFly Galleon Plugins Documentation

1. Introduction

WildFly Galleon Plugins project includes Galleon and Maven plugin implementations that are dedicated to building feature-packs (including generation of feature specs, packages and other resources) for WildFly releases and provisioning of WildFly-based distributions. These plugins can also be used by projects that integrate into or extend WildFly (Core, Servlet or Full base distributions).

2. Maven plugin

This chapter is dedicated to the Maven plugin that can be used to build WildFly-based feature-packs. Maven coordinates of the Maven plugin artifact are

Maven plugin installing feature-packs and provisioning distributions is a part of Galleon project itself. Please, refer to Galleon documentation for more information.

<dependency>
    <groupId>org.wildfly.galleon-plugins</groupId>
    <artifactId>wildfly-galleon-maven-plugin</artifactId>
    <version>4.2.0.Final</version>
</dependency>

2.1. Goals overview

generate-all-artifacts-list

Generates a list of all the artifacts required to install the full version of a feature-pack.

build-user-feature-pack

Creates feature-packs intended to be built on top WildFly feature-packs.

build-feature-pack

Creates a feature-pack archive from the provided resources in the WildFly fashion (used for official WildFly feature-packs).

2.2. generate-all-artifacts-list

2.2.1. wildfly-galleon:generate-all-artifacts-list

Full name: org.wildfly.galleon-plugins:wildfly-galleon-maven-plugin:4.2.0.Final:generate-all-artifacts-list

2.2.2. Description

Aggregate all artifact lists (offliners) of a feature-pack dependencies. In addition adds to the list the feature-pack itself and universe artifacts. The resulting list is attached as an artifact to the current project.

2.2.3. Attributes

Requires a Maven project to be executed.
Requires dependency resolution of artifacts in scope: runtime.
Binds by default to the lifecycle phase: compile.

Table 1. Required Parameters
Name	Type	Since	Description
`[fpArtifactId]`	`String`	`-`	(no description) Alias is: `feature-pack-artifact-id`.
`[fpGroupId]`	`String`	`-`	(no description) Alias is: `feature-pack-group-id`.

Table 2. Optional Parameters
Name	Type	Since	Description
`[extraArtifacts]`	`List`	`-`	(no description) Alias is: `extra-artifacts`.
`[fpVersion]`	`String`	`-`	(no description) Alias is: `feature-pack-version`.
`[offline]`	`boolean`	`-`	(no description) Default value is: `false`. Alias is: `offline`.

2.2.4. Parameter Details

extraArtifacts
(no description)

Type: java.util.List
Required: No
Alias: extra-artifacts

fpArtifactId
(no description)

Type: java.lang.String
Required: Yes
Alias: feature-pack-artifact-id

fpGroupId
(no description)

Type: java.lang.String
Required: Yes
Alias: feature-pack-group-id

fpVersion
(no description)

Type: java.lang.String
Required: No
Alias: feature-pack-version

offline
(no description)

Type: boolean
Required: No
Default: false
Alias: offline

2.3. build-user-feature-pack

2.3.1. wildfly-galleon:build-user-feature-pack

Full name: org.wildfly.galleon-plugins:wildfly-galleon-maven-plugin:4.2.0.Final:build-user-feature-pack

2.3.2. Description

This Maven Mojo is intended to be used to build feature-packs that depend on one of the WildFly feature-packs. This Maven mojo creates a WildFly style feature-pack archive from the provided resources according to the feature-pack build configuration file and attaches it to the current Maven project as an artifact. If no feature-pack build configuration is provided, some defaults are applied. The content of the future feature-pack archive is first created in the directory called feature-pack-layout under the module’s build directory which is then ZIPped to create the feature-pack artifact.

2.3.3. Attributes

Requires a Maven project to be executed.
Requires dependency resolution of artifacts in scope: runtime.
Binds by default to the lifecycle phase: compile.

Table 3. Required Parameters
Name	Type	Since	Description
`[resourcesDir]`	`String`	`-`	Represents the directory containing child directories `packages`, `feature_groups`, `modules` etc. Either an absolute path or a path relative to `configDir`. Default value is: `src/main/resources`. User property is: `wildfly.user.feature.pack.resourcesDir`. Alias is: `resources-dir`.

Table 4. Optional Parameters
Name	Type	Since	Description
`[buildName]`	`String`	`-`	The directory for the built artifact. Default value is: `${project.build.directory}`. User property is: `wildfly.user.feature.pack.buildName`.
`[configDir]`	`File`	`-`	The feature-pack build configuration file directory Default value is: `${basedir}`. User property is: `wildfly.user.feature.pack.configDir`. Alias is: `config-dir`.
`[configFile]`	`String`	`-`	The feature-pack build configuration file. Default value is: `wildfly-user-feature-pack-build.xml`. User property is: `wildfly.user.feature.pack.configFile`. Alias is: `config-file`.
`[fpLocation]`	`String`	`-`	The FPL for the generated feature-pack. Default value is: `${project.groupId}:${project.artifactId}:${project.version}`. Alias is: `feature-pack-location`.
`[releaseName]`	`String`	`-`	The name of the release the feature-pack represents which will be stored in the feature-pack’s `resources/wildfly/wildfly-tasks.properties` as `product.release.name` property. Default value is: `${product.release.name}`. Alias is: `release-name`.
`[taskProps]`	`Map`	`-`	Various properties that will be added to feature-pack’s `resources/wildfly/wildfly-tasks.properties`. NOTE: values of this parameter will overwrite the corresponding values from task-properties-file parameter, in case it’s also set. + Alias is: `task-properties`.
`[taskPropsFile]`	`File`	`-`	Path to a properties file content of which will be added to feature-pack’s `resources/wildfly/wildfly-tasks.properties` file that is used as the source of properties during file copying tasks with property replacement. Alias is: `task-properties-file`.

2.3.4. Parameter Details

buildName
The directory for the built artifact.

Type: java.lang.String
Required: No
User Property: wildfly.user.feature.pack.buildName
Default: ${project.build.directory}

configDir
The feature-pack build configuration file directory

Type: java.io.File
Required: No
User Property: wildfly.user.feature.pack.configDir
Default: ${basedir}
Alias: config-dir

configFile
The feature-pack build configuration file.

Type: java.lang.String
Required: No
User Property: wildfly.user.feature.pack.configFile
Default: wildfly-user-feature-pack-build.xml
Alias: config-file

fpLocation
The FPL for the generated feature-pack.

Type: java.lang.String
Required: No
Default: ${project.groupId}:${project.artifactId}:${project.version}
Alias: feature-pack-location

releaseName
The name of the release the feature-pack represents which will be stored in the feature-pack’s resources/wildfly/wildfly-tasks.properties as product.release.name property.

Type: java.lang.String
Required: No
Default: ${product.release.name}
Alias: release-name

resourcesDir
Represents the directory containing child directories packages, feature_groups, modules etc. Either an absolute path or a path relative to configDir.

Type: java.lang.String
Required: Yes
User Property: wildfly.user.feature.pack.resourcesDir
Default: src/main/resources
Alias: resources-dir

taskProps
Various properties that will be added to feature-pack’s resources/wildfly/wildfly-tasks.properties.
NOTE: values of this parameter will overwrite the corresponding values from task-properties-file parameter, in case it’s also set.

Type: java.util.Map
Required: No
Alias: task-properties

taskPropsFile
Path to a properties file content of which will be added to feature-pack’s resources/wildfly/wildfly-tasks.properties file that is used as the source of properties during file copying tasks with property replacement.

Type: java.io.File
Required: No
Alias: task-properties-file

2.3.5. Plugin configuration

Dependency on WildFly

The pom.xml of the project that makes use of this plugin must express a dependency on the WildFly feature-pack it is depending upon.

Feature-pack configuration

For typical user feature-packs construct (eg: package JBoss modules and define galleon layers), there is no need to define a feature-pack build configuration file. Everything can be configured from the plugin configuration element inside the pom.xml file.

For more advanced configuration, a file named wildfly-user-feature-pack-build.xml can be defined in the project root dir. This file complies with the wildfly-feature-pack-build.xml file syntax but only supports a subset of it.

The following items can be defined:

Feature Pack Location of the feature-pack.
Dependencies (transitives or directs) on other feature-packs.
Default packages.

For example:

<build xmlns="urn:wildfly:feature-pack-build:3.0" producer="org.foo:my-galleon-pack:1.0.0.Final">
    <dependencies>
        <dependency location="wildfly@maven(org.jboss.universe:community-universe):current#17.0.0.Final">
            <default-configs inherit="false"/>
            <packages inherit="false"/>
        </dependency>
    </dependencies>
    <default-packages>
        <package name="my.package1"/>
    </default-packages>
</build>

2.3.6. Galleon feature-pack content that can be defined with the mojo

JBoss module packages

The directory src/main/resources/modules contains JBoss modules to be turned into feature-pack packages. A package is created per JBoss module. JBoss module dependencies are reflected in the corresponding package dependencies.

A module can contain the binaries it wants to see installed or rely on the 'module.xml template' capability of the mojo. For example, here is an excerpt from a module.xml template:

<?xml version="1.0" encoding="UTF-8"?>
<module name="org.postgresql.jdbc" xmlns="urn:jboss:module:1.8">
    <resources>
        <artifact name="${org.postgresql:postgresql}"/>
    </resources>
    <dependencies>
        <module name="javax.api"/>
        <module name="javax.transaction.api"/>
    </dependencies>
</module>

It looks pretty much like the final module.xml except that the artifact name is an expression which should be replaced with either the complete artifact coordinates in case of a thin distribution, e.g.

<?xml version="1.0" encoding="UTF-8"?>
<module name="org.postgresql.jdbc" xmlns="urn:jboss:module:1.8">
    <resources>
        <artifact name="org.postgresql:postgresql:9.4.1211"/>
    </resources>
    <dependencies>
        <module name="javax.api"/>
        <module name="javax.transaction.api"/>
    </dependencies>
</module>

or the resource-root element in case of a fat distribution, e.g.

<module name="org.postgresql.jdbc" xmlns="urn:jboss:module:1.8">

    <resources>
        <resource-root path="postgresql-9.4.1211.jar"/>
    </resources>

    <dependencies>
        <module name="javax.api"/>
        <module name="javax.transaction.api"/>
    </dependencies>

module.xml template processing is happening at provisioning time and depends on the kind of distribution being provisioned. That is controlled by the plugin option jboss-maven-dist=true|false. true to provision a thin installation, false to provision a fat installation.

If you are packaging JBoss module using the "module.xml template" you must express the dependencies on the actual artifacts you want to see provisioned in the pom.xml file.

It is possible that a module depends on another module which is not found in the current feature-pack. In that case, the feature-pack that contains the package representing the module from the dependency must be declared as the dependency of the current feature-pack in the feature-pack build config file. If the dependency could not be resolved locally (among the modules included in the current feature-pack), the module will be looked up in the dependencies of the current feature-pack (in the order the dependencies are specified in the feature-pack build config file).

In case a module dependency could not be resolved neither locally nor in the feature-pack dependencies, an error will be thrown with the corresponding message.

The package generated for a JBoss module can still be customized by, e.g., adding pm/wildfly/tasks.xml to it in src/main/resources/packages. In this case the package dir in src/main/resources/packages has to include only the content that the generated package is missing. It doesn’t have to include package.xml unless the generated one has to be replaced with a custom one.

Custom, add-ons and layers types of JBoss modules

Custom modules are defined directly under modules directory.
add-ons are defined under modules/system/add-ons/<add-on name> directory.
layers are defined under modules/system/layers/<layer name> directory. You must also define the file layers.conf under modules directory.

Galleon packages

The directory src/main/resources/packages/ contains galleon packages. Packages contain content (other than JBoss modules) you want to see provisioned along with a layer and/or configuration.

Documentation to help you define packages can be found here.

Galleon Layers

You can define your own layers (eg: drivers, datasources, customized subsystem) that can be then assembled with WildFly built-in layers to compose a configuration.

The directory src/main/resources/layers contains the layers definitions.

Layers are defined for a given model of configuration. Configuration model can be one of standalone, host or domain. The layers defined for a given configuration model are located inside a directory named with the configuration model: layers/<config model name>/<layer name>/layer-spec.xml

Example of a layer that defines the configuration for a mysql driver and include the driver package (a JBoss module) named com.mysql.jdbc.

<?xml version="1.0" ?>
<layer-spec xmlns="urn:jboss:galleon:layer-spec:1.0" name="mysql-driver">
    <feature spec="subsystem.datasources">
        <feature spec="subsystem.datasources.jdbc-driver">
            <param name="driver-name" value="mysql"/>
            <param name="jdbc-driver" value="mysql"/>
            <param name="driver-xa-datasource-class-name" value="com.mysql.jdbc.jdbc2.optional.MysqlXADataSource"/>
            <param name="driver-module-name" value="com.mysql.jdbc"/>
        </feature>
    </feature>
    <packages>
        <package name="com.mysql.jdbc"/>
    </packages>
</layer-spec>

Documentation to help you define layers can be found here.

Galleon feature-groups

You can define your own feature-groups that can then be re-used when defining configurations.

The directory src/main/resources/feature_groups contains the feature-groups definitions. A feature-group is defined inside the file <feature-group name>.xml

For example:

<?xml version="1.0" encoding="UTF-8"?>
<feature-group-spec name="my-feature-group" xmlns="urn:jboss:galleon:feature-group:1.0">
    <feature-group name="another-feature-group"/>
    <feature spec="interface">
        <param name="interface" value="my-interface"/>
        <param name="inet-address" value="192.168.1.1"/>
    </feature>
</feature-group-spec>

Documentation to help you define feature-groups can be found here.

Galleon default configurations

You can define default configurations to be provisioned by galleon. Default configurations are defined in src/main/resources/configs/<config model>/<config name>/config.xml file. Configuration model can be one of standalone, host or domain.

For example:

<config xmlns="urn:jboss:galleon:config:1.0" name="standalone.xml" model="standalone">
    <layers>
        <include name="cloud-profile"/>
        <include name="my-layer"/>
    </layers>
    <feature-group name="my-feature-group"/>
</config>

Documentation to help you define default configurations can be found here.

2.4. build-feature-pack

2.4.1. wildfly-galleon:build-feature-pack

Full name: org.wildfly.galleon-plugins:wildfly-galleon-maven-plugin:4.2.0.Final:build-feature-pack

2.4.2. Description

This Maven mojo creates a WildFly style feature-pack archive from the provided resources according to the feature-pack build configuration file and attaches it to the current Maven project as an artifact. The content of the future feature-pack archive is first created in the directory called layout under the module’s build directory which is then ZIPped to create the feature-pack artifact.

2.4.3. Attributes

Requires a Maven project to be executed.
Requires dependency resolution of artifacts in scope: compile+runtime.
Binds by default to the lifecycle phase: compile.

Table 5. Required Parameters
Name	Type	Since	Description
`[featureSpecsOutput]`	`File`	`-`	The directory where the generated feature specs are written. Default value is: `${project.build.directory}/resources/features`. Alias is: `feature-specs-output`.
`[moduleTemplatesDir]`	`File`	`-`	Used only for feature spec generation and points to a directory where the module templates from the dependent feature packs are gathered before they are transformed and copied under their default destination `wildflyHome`/modules. Intended mainly for debugging. Default value is: `${project.build.directory}/module-templates`. User property is: `wfgp.moduleTemplatesDir`. Alias is: `module-templates`.
`[resourcesDir]`	`String`	`-`	Represents the directory containing child directories `packages`, `feature_groups`, `modules` etc. Either an absolute path or a path relative to `configDir`. Default value is: `src/main/resources`. User property is: `wildfly.feature.pack.resourcesDir`. Alias is: `resources-dir`.
`[wildflyHome]`	`File`	`-`	Used only for feature spec generation and points to a directory from which the embedded WildFly instance will be started that is used for exporting the meta-model. Intended mainly for debugging. Default value is: `${project.build.directory}/wildfly`. User property is: `wfgp.wildflyHome`. Alias is: `wildfly-home`.

Table 6. Optional Parameters
Name	Type	Since	Description
`[buildName]`	`String`	`-`	The directory for the built artifact. Default value is: `${project.build.directory}`. User property is: `wildfly.feature.pack.buildName`.
`[configDir]`	`File`	`-`	The feature-pack build configuration file directory Default value is: `${basedir}`. User property is: `wildfly.feature.pack.configDir`. Alias is: `config-dir`.
`[configFile]`	`String`	`-`	The feature-pack build configuration file. Default value is: `wildfly-feature-pack-build.xml`. User property is: `wildfly.feature.pack.configFile`. Alias is: `config-file`.
`[forkEmbedded]`	`boolean`	`-`	Used only for feature spec generation and indicates whether to launch the embedded server to read feature descriptions in a separate process Alias is: `fork-embedded`.
`[fpArtifactId]`	`String`	`-`	The artifactId for the generated feature-pack. Default value is: `${project.artifactId}`. Alias is: `feature-pack-artifact-id`.
`[releaseName]`	`String`	`-`	The name of the release the feature-pack represents which will be stored in the feature-pack’s `resources/wildfly/wildfly-tasks.properties` as `product.release.name` property. Default value is: `${product.release.name}`. Alias is: `release-name`.
`[taskProps]`	`Map`	`-`	Various properties that will be added to feature-pack’s `resources/wildfly/wildfly-tasks.properties`. NOTE: values of this parameter will overwrite the corresponding values from task-properties-file parameter, in case it’s also set. + Alias is: `task-properties`.
`[taskPropsFile]`	`File`	`-`	Path to a properties file content of which will be added to feature-pack’s `resources/wildfly/wildfly-tasks.properties` file that is used as the source of properties during file copying tasks with property replacement. Alias is: `task-properties-file`.

2.4.4. Parameter Details

buildName
The directory for the built artifact.

Type: java.lang.String
Required: No
User Property: wildfly.feature.pack.buildName
Default: ${project.build.directory}

configDir
The feature-pack build configuration file directory

Type: java.io.File
Required: No
User Property: wildfly.feature.pack.configDir
Default: ${basedir}
Alias: config-dir

configFile
The feature-pack build configuration file.

Type: java.lang.String
Required: No
User Property: wildfly.feature.pack.configFile
Default: wildfly-feature-pack-build.xml
Alias: config-file

featureSpecsOutput
The directory where the generated feature specs are written.

Type: java.io.File
Required: Yes
Default: ${project.build.directory}/resources/features
Alias: feature-specs-output

forkEmbedded
Used only for feature spec generation and indicates whether to launch the embedded server to read feature descriptions in a separate process

Type: boolean
Required: No
Alias: fork-embedded

fpArtifactId
The artifactId for the generated feature-pack.

Type: java.lang.String
Required: No
Default: ${project.artifactId}
Alias: feature-pack-artifact-id

moduleTemplatesDir
Used only for feature spec generation and points to a directory where the module templates from the dependent feature packs are gathered before they are transformed and copied under their default destination wildflyHome/modules. Intended mainly for debugging.

Type: java.io.File
Required: Yes
User Property: wfgp.moduleTemplatesDir
Default: ${project.build.directory}/module-templates
Alias: module-templates

releaseName
The name of the release the feature-pack represents which will be stored in the feature-pack’s resources/wildfly/wildfly-tasks.properties as product.release.name property.

Type: java.lang.String
Required: No
Default: ${product.release.name}
Alias: release-name

resourcesDir
Represents the directory containing child directories packages, feature_groups, modules etc. Either an absolute path or a path relative to configDir.

Type: java.lang.String
Required: Yes
User Property: wildfly.feature.pack.resourcesDir
Default: src/main/resources
Alias: resources-dir

Type: java.util.Map
Required: No
Alias: task-properties

Type: java.io.File
Required: No
Alias: task-properties-file

wildflyHome
Used only for feature spec generation and points to a directory from which the embedded WildFly instance will be started that is used for exporting the meta-model. Intended mainly for debugging.

Type: java.io.File
Required: Yes
User Property: wfgp.wildflyHome
Default: ${project.build.directory}/wildfly
Alias: wildfly-home

2.4.5. Feature-pack packages

The Maven project module which creates a feature-pack may describe its packages and/or provide more data for the packages generated from JBoss modules in the Maven module’s src/main/resources/packages.

Every child directory of src/main/resources/packages represents a package with the directory name being the package name. The content of the package directory is going to be copied to the corresponding package directory in the feature-pack.

The usual package directory structure is:

package_name
|- content/
|- pm/
|  `- wildfly/
|     `- tasks.xml
`- package.xml

In general, the only required child of the package directory is package.xml.

Package content directory includes content that will be copied to the installation root directory when the package is installed.

pm/wildfly/tasks.xml file is optional, it may include instructions to copy and/or delete files and diretcories, create directories, resolve and copy Maven artifacts to the installation directory, etc. These tasks are executed when the content of all the packages has been copied into the installation.

2.4.6. Generating JBoss module packages

JBoss modules of the distribution are turned into feature-pack packages. A package is created per JBoss module. JBoss module dependencies are reflected in the corresponding package dependencies.

JBoss modules packages don’t have to be manually described in src/main/resources/packages.

Traditionally, WildFly-based builds use module.xml templates to generate the final module.xml files based on the distribution type selected: thin (when the JBoss module artifacts are loaded directly from the Maven repository at runtime) or thick (when the JBoss module artifacts are resolved and copied to the distribution directory at provisioning time).

The Maven module that is building a feature-pack may include src/main/resources/modules/system/layers directory containing module.xml templates. The mojo will read those and generate a package per module.xml.

For example, here is an excerpt from a module.xml template:

<module xmlns="urn:jboss:module:1.8" name="org.jboss.as.jmx">
    <properties>
        <property name="jboss.api" value="private"/>
    </properties>

    <exports>
        <exclude path="org/jboss/as/jmx/logging"/>
    </exports>

    <resources>
        <artifact name="${org.wildfly.core:wildfly-jmx}"/>
    </resources>

    <dependencies>
        <!-- skipped content -->

<module name="org.jboss.as.jmx" xmlns="urn:jboss:module:1.8">
    <properties>
        <property name="jboss.api" value="private"/>
    </properties>

    <exports>
        <exclude path="org/jboss/as/jmx/logging"/>
    </exports>

    <resources>
        <artifact name="org.wildfly.core:wildfly-jmx:5.0.0.Beta3-SNAPSHOT"/>
    </resources>

    <dependencies>
        <!-- skipped content -->

or the resource-root element in case of a thick distribution, e.g.

<module name="org.jboss.as.jmx" xmlns="urn:jboss:module:1.8">
    <properties>
        <property name="jboss.api" value="private"/>
    </properties>

    <exports>
        <exclude path="org/jboss/as/jmx/logging"/>
    </exports>

    <resources>
        <resource-root path="wildfly-jmx-5.0.0.Beta3-SNAPSHOT.jar"/>
    </resources>

    <dependencies>
        <!-- skipped content -->

module.xml template processing is happening at provisioning time and depends on the kind of distribution being provisioned.

In case a module dependency could not be resolved neither locally nor in the feature-pack dependencies, an error will be thrown with the corresponding message.

modules.all package

If a feature-pack includes JBoss modules, in addition to the module packages, the mojo will generate a package called modules.all. This package will not contain any content but will simply depend on all the module packages generated for this feature-pack. This package exists for convenience only to be able to install all the modules from the feature-pack (and its dependencies) by including a single package.

Original WildFly feature-packs include modules.all into the default package list at the moment to follow the legacy approach of building distributions. This is configured in the feature-pack build config file.

2.5. Feature-pack build config file (wildfly-feature-pack-build.xml)

Feature-pack building starts with this file. The file describes the feature-pack in terms of its dependencies on other feature-packs, default packages, configs and other options such as from which artifact groups to extract schemas into the distribution’s docs/schema directory.

If the file includes feature-pack dependencies, those feature-packs must be resolvable as Maven artifacts during the build process. They will be explored to collect the provisioning descriptions (such as feature-pack.xml, etc) of the dependencies.

Normally, most of the content of this file will be copied directly into the final feature-pack.xml generated by the mojo. Here is an example from WildFly Servlet feature-pack build config file

<build xmlns="urn:wildfly:feature-pack-build:3.0" producer="wildfly-servlet@maven(org.jboss.universe:community-universe):current">
    <dependencies>
        <dependency group-id="org.wildfly.core" artifact-id="wildfly-core-galleon-pack">
            <name>org.wildfly.core:wildfly-core-galleon-pack</name>
            <packages inherit="false">
                <exclude name="product.conf"/>
            </packages>
            <default-configs inherit="false"/>
        </dependency>
    </dependencies>
    <default-packages>
        <package name="modules.all"/>
        <package name="docs"/>
    </default-packages>
    <package-schemas>
        <group name="org.jboss.as"/>
        <group name="org.wildfly"/>
        <group name="org.wildfly.core"/>
    </package-schemas>
    <config model="standalone">
        <packages>
            <package name="product.conf" optional="true"/>
            <package name="misc.standalone"/>
        </packages>
    </config>

    <!-- other configs are skipped -->

    <generate-feature-specs>
        <extensions>
            <standalone>
                <extension>org.jboss.as.ee</extension>
                <extension>org.jboss.as.naming</extension>
                <extension>org.jboss.as.security</extension>
                <extension>org.wildfly.extension.undertow</extension>
            </standalone>
            <domain>
                <extension>org.jboss.as.ee</extension>
                <extension>org.jboss.as.naming</extension>
                <extension>org.jboss.as.security</extension>
                <extension>org.wildfly.extension.undertow</extension>
            </domain>
        </extensions>
    </generate-feature-specs>
</build>

All the elements in the above example except for package-schemas and generate-feature-specs are actual feature-pack.xml content that will be copied to the resulting feature-pack.xml as-is.

Extracting schemas

The presence of element package-schemas instructs the mojo to create a package called docs.schema. The package includes no content but a file with Maven artifact groupIds from which XSD schemas should be extracted into the distribution’s docs/schema directory, in case docs.schema package was selected to be installed (it is by default).

Feature specs generation

Feature-pack may or may not include feature specs (XML files describing configuration features). Feature specs are included only if the feature-pack includes one or more subsystems that should be added to the confuration when the feature-pack is installed.

In WildFly feature-packs, feature specs are generated. generate-feature-specs is an element that lists extensions included in the feature-pack for which feature specs should be generated.

feature specs are generated using generate-feature-specs goal of the plugin.

Adding provisioning plugins

Feature-packs that depend on WildFly (or WildFly Core), normally, don’t need to add any provisioning plugins to be usable by Galleon. WildFly Core feature-pack includes the plugins that are used during provisioning for all the feature-packs that (directly or indirectly) depend on it. Here is a snipped from WildFly Core wildfly-feature-pack-build.xml that adds WildFly provisioning plugin JARs:

<build xmlns="urn:wildfly:feature-pack-build:3.0" producer="wildfly-core@maven(org.jboss.universe:community-universe):current">
    <!-- content skipped -->

    <plugins>
        <plugin artifact="org.wildfly.galleon-plugins:wildfly-galleon-plugins"/> (1)
    </plugins>

    <resources>
        <copy artifact="org.wildfly.galleon-plugins:wildfly-config-gen" to="wildfly/wildfly-config-gen.jar"/> (2)
    </resources>

    <!-- content skipped -->
</build>

1	`plugins` element may include multiple `plugin` elements specifying Maven artifact coordinates of the plugin
2	`copy` element under `resources` instructs to copy the specified artifact to the feature-pack `resources` directory

Both artifact coordinates above are missing versions. Although the versions could specified, in this case they will be resolved from the Maven project dependencies at the plugin execution time.