WildFly Glow Documentation

1. Introduction

WildFly Glow is an evolution of the WildFly Galleon provisioning tooling.

The goal of this project is to offer tooling allowing to identify the set of Galleon Feature-packs and Layers that are required by your application. The entry-point of this discovery is your application.

1.1. Automatic identification of WildFly Galleon Layers

Today, in order to trim a WildFly server to fit the application requirements, you have to first identify the set of WildFly Galleon Layers to use.

WildFly Glow identifies the Layers for you by scanning your application war (jar or ear) files.

This application to Galleon Layers mapping is based on rules contained in WildFly Galleon Layers (Starting WildFly 29). These rules express the Java types and artifacts (XML descriptors, properties files, …) that are bound to the usage of a given Galleon Layer. An example of rule can be found in the jaxrs Layer.

Once the Layers are identified, the Galleon Feature-packs that define them are selected and included.

1.2. Centralized knowledge of WildFly Galleon Feature-packs.

WildFly can be extended with additional Galleon Feature-packs (e.g.: datasources, gRPC, keycloak, cloud, myfaces, resteasy-spring, …).

WildFly Glow has, per WildFly version, the knowledge of some compatible Galleon Feature-packs (this information is stored in this github project).

In order for these extras Feature-packs to be recognized by WildFly Glow, they must have their defined Layers annotated with rules.

1.3. Incubating feature-packs.

Feature-packs that are developed outside of the WildFly feature process can be registered in the "incubating" space. This space can be explicitly enabled when discovering provisioning configuration. WildFly Glow has, per WildFly version, the knowledge of 'incubating' compatible Galleon Feature-packs (this information is stored in this directory).

In order for these extras feature-packs to be recognized by WildFly Glow, they must have their defined Layers annotated with rules.

1.4. Going beyond discovered Galleon Layers

WildFly Glow does more than identifying Galleon Feature-packs and Layers.

1.4.1. Provisioning

WildFly Glow CLI allows you to provision a WildFly server, a WildFly Bootable JAR, produce a Docker image and deploy your application to OpenShift.

OpenShift provisioning

A good way to start with OpenShift is by using the OpenShift Sandbox. You can create a cluster in few clicks.

Pre-requisites

Once you have a custer up and running, there are few steps needed in order for WildFly Glow to log onto the cluster:

Download the oc command from your cluster. Click on the ? icon on the top right corner of the OpenShift admin console, then select Command Line Tools, then download oc for your platform.
Retrieve the command to log to the Cluster. Click on your user name on the top right corner, then select Copy login command. This will open a page, copy the login command. That should be something like: oc login --token=sha256~ITC16QZxiVk5vm7NCdrRIx2yqvlB-L_6Wg-BrtIhnLE --server=https://api.sandbox-m3.1530.p1.openshiftapps.com:6443
Paste the login command in your terminal.

WildFly Glow can now interact with your cluster.

Deploying to OpenShift

That is done from the wildfly-glow command line tool. You can specify --cloud --provision OPENSHIFT to the scan command. For example:

wildfly-glow scan examples/kitchensink.war --cloud --provision OPENSHIFT

The kitchensink war file is analyzed, the Galleon configuration is generated, then both the war and the configuration are sent to OpenShift to start a server provisioning and create your application deployment.

At the end of the build, the application is deployed and the route to your application inside the cluster is printed. Use it to interact with your application.

Note: The OpenShift resources yaml files are generated in the directory server-<wildfly version>/resources

Note: the support for OpenShift is currently specified by this WildFly Glow project GitHub Issue.

Automatic deployment of PostGreSQL, MySQL, MariaDB, AMQ JMS Broker and Keycloak

If WildFly Glow detects the need for these technologies, it will automatically deploy the required servers and will bound the application to them.

High Availability support

When the HA profile is enabled, 2 pods will be created for the deployment. The JGroups dns.DNS_PING protocol is enabled for the members of the cluster to discover each others.

1.4.2. OpenShift dry-run mode

When using the --dry-run option, WildFly glow will not interact with the cluster but will generate all the needed resources that are required to build and deploy your application in the cluster of your choice. You can then assemble the images and deploy to your cluster in a flexible way. The generated resources allow, for example, to setup a Tekton pipeline to produce images, and use Argo CD to manage your k8s resources.

Docker files for the server and application images

WildFly Glow separates the build of your application image into 2 steps. A first step to build the server image that only contains the WildFly server. A second step that, from the server image, produces an application image that contains the deployments, the WildFly CLI script (if any) and the bash initialization script (if any).

In order to share the server image between various applications, a server image tag is computed based on all that makes the content of the server unique:

The generated provisioning XML file
Env variables (if any) used at provisioning time.
WildFly channel (if any) used at provisioning time.

Bulding and pushing the server image

Once WildFly Glow has generated the resources, you need to:

Provision the server using the generated <server-version>/galleon/provisioning.xml file (using Galleon CLI) inside the directory <server-version>/docker/server/server.
Build and push the server image using the server tag generated in <server-version>/docker/image.properties and the docker file <server-version>/docker/server/Dockerfile. Makes sure to run the build inside the directory <server-version>/docker/server, that is the expected build docker context.

Bulding and pushing the application image

Once you have pushed the server in a container image repository, you need to:

In the <server-version>/docker/app/Dockerfile file replace the WILDFLY_GLOW_SERVER_IMAGE_REPOSITORY placeholder with the pushed server image repository.
Build and push the application image using the application tag generated in <server-version>/docker/image.properties and the docker file <server-version>/docker/app/Dockerfile. Makes sure to run the build inside the directory <server-version>/docker/app, that is the expected build docker context.

Updating the k8s deployment with the generated application image

The generated deployment (or the statefulSet in case of HA application) in <server-version>/resources/deployment/ directory references the container image using the placeholder WILDFLY_GLOW_APP_IMAGE_REPOSITORY. Replaces it with the actual application image repository.

You are good to go. You can now create the k8s resources in your cluster.

1.4.3. WildFly additional features discovery

Some WildFly server features can’t be discovered by scanning application deployment. A good example is the usage of SSL to secure the http access. Another one is the need for WildFly tooling (e,g,: WildFly CLI, elytron tooling, …). WildFly Glow allows you to include, according to what has been discovered in the deployment, a set of WildFly features called add-ons that makes sense for your application.

1.4.4. Connection to databases

WildFly Glow detects that your application requires a datasource and will suggest you with database add-ons to be included in order to connect to the DB of your choice (postgresql, mysql, …).

1.5. WildFly Glow tooling

WildFly Glow tooling is composed of 3 parts:

A Command Line interface (wildfly-glow CLI) that scan your deployment and can provision a WildFly server, a WildFly Bootable JAR and a Docker image (to be deployed on Kubernetes). From the CLI you can discover the list of available add-ons, the list of WildFly server versions you can use (the latest WildFly major release being the default).
An integration with the WildFly Maven plugin (Starting 5.0.0.Alpha2) package goal, to provision a WildFly server without specifying Feature-packs and Layers.
A Maven plugin to scan Arquillian deployments in your tests and produce a provisioning.xml file that can be consumed by WildFly provisioning tooling.

1.6. Support for WildFly Stability

WildFly Glow CLI has a support for WildFly Stability.

WildFly Glow can detect and report that some of the discovered Galleon layers contain content that are only available at a given stability and advise you to enable this stability level (by using the --config-stability-level=<stability level> option.

When provisioning a server, if a stability level has been specified, WildFly Glow will display how a WildFly server must be started to enable the stability level. For example: standalone.sh --stability=preview

When provisioning for OpenShift, if a stability level has been specified, WildFly Glow will configure the generated OpenShift Deployment to start the server with the required stability level.

To list the options related to the WildFly stability feature, call wildfly-glow scan --help and look for --*stability-level options.

2. WildFly Glow Command Line

Download the latest WildFly Glow CLI zip file from github releases
Unzip the file wildfly-glow-<version>.zip
cd wildfly-glow-<version>
To display the CLI help call: ./wildfly-glow
To install the automatic CLI commands completion call: source <(./wildfly-glow completion)
To scan a first deployment call: ./wildfly-glow scan ./examples/kitchensink.war

3. WildFly Maven Plugin integration

WildFly Glow has been integrated in WildFly Maven Plugin 5.x starting with 5.0.0.Alpha2 version.

When using version 4.2 of the WildFly Maven Plugin you must specify the WildFly Galleon Feature-packs and Galleon Layers to use to provision WIldFly. For example, a plugin configuration extract to provision WildFly for cloud with support to connect to postgresql database.

<plugin>
    <groupId>org.wildfly.plugins</groupId>
    <artifactId>wildfly-maven-plugin</artifactId>
    <version>4.2.0.Final</version>
    <configuration>
        <feature-packs>
            <feature-pack>
                <location>org.wildfly:wildfly-galleon-pack:30.0.1.Final</location>
            </feature-pack>
            <feature-pack>
                <location>org.wildfly.cloud:wildfly-cloud-galleon-pack:5.0.0.Final</location>
            </feature-pack>
            <feature-pack>
                <location>org.wildfly:wildfly-datasources-galleon-pack:6.0.0.Final</location>
            </feature-pack>
        </feature-packs>
        <layers>
            <layer>jaxrs-server</layer>
            <layer>postgresql-datasource</layer>
        </layers>
        <runtime-name>ROOT.war</runtime-name>
    </configuration>
    <executions>
        <execution>
            <goals>
                <goal>package</goal>
            </goals>
        </execution>
    </executions>
</plugin>

The set of Feature-packs versions that are compatible with WildFly and the set of Galleon Layers that are required to properly execute your application must be known and added to the configuration. This does create some complexity.

The integration of WildFly Glow in the WildFly Maven plugin allows to delegate to the plugin the provisioning configuration. The plugin scans your deployment and provision a server based on what has been discovered.

The plugin configuration becomes:

<plugin>
    <groupId>org.wildfly.plugins</groupId>
    <artifactId>wildfly-maven-plugin</artifactId>
    <version>5.0.0.Beta1</version>
    <configuration>
        <discover-provisioning-info/>
        <runtime-name>ROOT.war</runtime-name>
    </configuration>
    <executions>
        <execution>
            <goals>
                <goal>package</goal>
            </goals>
        </execution>
    </executions>
</plugin>

When executing the plugin with such configuration, the set of discovered Feature-packs and Layers are used to provision the WildFly server. In addition, provisioning information is displayed and the file target/glow-scan/provisioning.xml is generated. This allows you to see what the plugin has discovered and that it is in line with what you are expecting.

3.1. Specifying a WildFly version

By default the latest WildFly version is used, you can specify a given WildFly version (starting with WildFly 29.0.0.Final). To do so extend the discover-provisioning-info element:

<discover-provisioning-info>
    <version>30.0.0.Final</version>
</discover-provisioning-info>

3.2. Adding add-ons

If your application requires some additional features not discovered in your deployment, you can specify add-ons:

<discover-provisioning-info>
    <add-ons>
        <add-on>ssl</add-on>
        <add-on>openapi</add-on>
    </add-ons>
</discover-provisioning-info>

According to what has been discovered in your deployment, the plugin can suggest a set of add-ons that would make sense for your application. You should see the following message being displayed:

Some suggestions have been found. You could enable suggestions with --suggest option (if using the WildFly Glow CLI) or <suggest>true</suggest> (if using the WildFly Maven Plugin).

To print the suggestions, evolve the discover-provisioning-info:

<discover-provisioning-info>
    <suggest>true</suggest>
</discover-provisioning-info>

Note: In order to find-out the set of possible add-ons you could add, you could also use the WildFly Glow CLI command line that offers a command to list the available add-ons for a given WildFly version.

3.3. Configuring add-ons

It can happen that the added add-on(s) require some environment variables to be set at server execution time. The plugin will display the set of expected environment variables (and values) that you should set when starting the server. For example, when adding the postgresql add-on, the following warning is displayed:

strongly suggested configuration
postgresql-datasource:
 - POSTGRESQL_DATABASE=Defines the database name to be used in the datasource’s `connection-url` property.
 - POSTGRESQL_JNDI=java:jboss/datasources/PostgreSQLDS
 - POSTGRESQL_PASSWORD=Defines the password for the datasource.
 - POSTGRESQL_USER=Defines the username for the datasource.

3.4. Specifying the cloud execution context

If the application you are building targets a cloud execution extend the discover-provisioning-info element:

<discover-provisioning-info>
    <context>cloud</context>
</discover-provisioning-info>

When cloud is enabled, some extra Galleon Feature-packs and Galleon Layers will be added to provision a WildFly server that properly executes on OpenShift or Kubernetes.

3.5. HA (High Availability) support

High availability support implies that some Galleon Layers are included and some are excluded in order to provision a valid HA server.

For example, to provision an HA server to run distributed ejb, when using WildFly Maven Plugin 4.2, you would have to specify:

<layers>
    <layer>jaxrs-server</layer>
    <layer>ejb-lite</layer>
    <layer>ejb-dist-cache</layer>
</layers>
<excluded-layers>
    <layer>ejb-local-cache</layer>
</excluded-layers>

In this example, the local ejb infinispan cache is excluded and the ejb infinispan distributed one is added.

WildFly Glow handles that for you, simply evolve the discover-provisioning-info element with the ha profile:

<discover-provisioning-info>
    <profile>ha</profile>
</discover-provisioning-info>

The Galleon Layers inclusions and exclusions are automatically handled.

3.6. Dry-run

You can configure the plugin to just scan the deployment and not provision a server:

<discover-provisioning-info></discover-provisioning-info>
<dry-run>true</dry-run>

3.7. Error handling

Some errors can be discovered by the plugin during deployment scanning. For example an add-on is required and must be added. If some errors are found the plugin execution is aborted and you need to take an action (e.g.: add the missing add-on). In some cases, it can appear that the error is actually not problematic and can be ignored, to do so, evolve the discover-provisioning-info:

<discover-provisioning-info>
    <failsOnError>false</failsOnError>
</discover-provisioning-info>

3.8. Support for WildFly Preview

If you are targeting deployment to the WildFly Preview server, evolve the discover-provisioning-info:

<discover-provisioning-info>
    <preview>true</preview>
</discover-provisioning-info>

3.9. Specifying additional Galleon Layers

In case your application is requiring some extras Galleon Layers due to the fact that some API usages are hidden in your implementation (e.g.: Java reflection, usage of JNDI API), you can evolve the discover-provisioning-info:

<discover-provisioning-info>
    <layersForJndi>
        <layer>mail</layer>
    </layersForJndi>
</discover-provisioning-info>

In this example, the mail Galleon Layer is added.

3.10. Excluding archives

In case your application packages some jars, you can exclude such jars from the scanning. To do so evolve the discover-provisioning-info:

<discover-provisioning-info>
    <excludedArchives>
        <archive>foo.jar</archive>
        <archive>example*</archive>
    </excludedArchives>
</discover-provisioning-info>

3.11. Enabling spaces

In case you want to have access to feature-packs registered in some additional spaces (e.g.: in the 'incubating' space), you can provide the list of spaces to enable. To do so evolve the discover-provisioning-info:

<discover-provisioning-info>
    <spaces>
        <space>incubating</space>
    </spaces>
</discover-provisioning-info>

3.12. Printing matching rules

You can print the rules that selected the Galleon Layers. To do so set the <verbose> argument.

<discover-provisioning-info>
    <verbose>true</verbose>
</discover-provisioning-info>

An example of output:

...
layers inclusion rules
* ee-core-profile-server
  - BASE_LAYER
* ee-concurrency
  - JAVA_TYPE: [jakarta.enterprise.concurren.*]
* undertow-https
  - ADD_ON
...

4. WildFly Glow Arquillian Maven plugin

Maven coordinates of the Maven plugin artifact are:

<dependency>
    <groupId>org.wildfly.glow</groupId>
    <artifactId>glow-arquillian-plugin</artifactId>
    <version>1.2.0.Final</version>
</dependency>

This Maven plugin is dedicated to help you automate WildFly provisioning when using Arquillian.

The plugin should be run during test build phase, after the tests have been compiled but prior to any WildFly provisioning plugin (Galleon Maven plugin, WildFly Maven plugin or WildFly Bootable JAR Maven plugin) execution.

The tests deployments (returned by static methods annotated with the @org.jboss.arquillian.container.test.api.Deployment annotation), are scanned by the plugin to discover the set of Galleon Layers. It then generates the target/glow-scan/provisioning.xml file containing what has been discovered. This file can then be consumed by provisioning tooling to do the actual server provisioning.

In order to validate that what the scanning has discovered is expected, you can configure the wildfly-glow-arquillian-plugin maven plugin to contain the element <expected-discovery>. For example:

<expected-discovery>[cdi, ee-integration, ejb, ejb-lite, elytron-oidc-client, naming, servlet]==>ee-core-profile-server,ejb,elytron-oidc-client</expected-discovery>

The left part of the arrow contains the list of the discovered Layers according to the scanning. The right part is what will get provisioned. Composed of a base Layer (always ee-core-profile-server) and a list of the discovered Layers that has been cleaned-up to avoid to include dependencies.

Note: In case the ha profile is enabled, you need to prefix the expected discovery with the [ha] prefix. For example:

<expected-discovery>[ha][cdi, ee-integration, ejb, ejb-lite, elytron-oidc-client, naming, servlet]==>ee-core-profile-server,ejb,elytron-oidc-client</expected-discovery>

BTW: The WildFly integration tests contain a lot of examples of WildFly Glow scanning executions that you can use as a starting-point.

In case the test depends on some not discoverable features, you have the ability to explicitly add add-ons to enrich the set of provisioned Layers (using the <add-ons> configuration element).

In addition, it can happen that some errors are identified by WildFly Glow. Some need to be fixed, some could be fine in the context of the tests. Errors that are fine in the context of the test can be ignored using the <expected-errors> element.

Known WildFly Glow discovered errors:

jakarta.naming.Context or InitialContext lookup: In case some lookup is present in the test code that could hide the usage of a Layer not discovered. You can configure the plugin with <add-layers-for-jndi> to add the Layers that are required (if any) and hidden.
ambiguous resource injection: An un-typed resource injection could hide a required Layer. You can configure the plugin with <add-layers-for-jndi> to list the Layers that are required (if any) and hidden.
an add-on of the messaging family is expected by the messaging-activemq layer. One of embedded or remoting messaging add-on is required.
unbound datasources error: <name of ds>: A datasource is expected but not found in the deployment. That is generally an error to ignore, the test itself should add the datasource during the setup.
no default datasource found error: It has been identified that a default datasource is required. That can be fixed by adding the add-on h2-database:default.

You can disable the check for errors by setting <check-errors>false</check-errors>.

Note: When <verbose>true</verbose> is set, the list of expected errors can be different (it contains more details on the error), make sure to suppress the expected errors when debugging or set <check-errors>false</check-errors>.

4.1. Selecting a surefire execution to scan

You can select a given surefire execution to scan. To do so add the following element to the plugin configuration:

<surefireExecutionForIncludedClasses>ts.surefire.clustering.microprofile</surefireExecutionForIncludedClasses>

In this example, the tests executed by the surefire execution with id ts.surefire.clustering.microprofile are scanned.

4.2. Aggregating multiple server configurations in the same provisioning.xml

You can express an aggregate name that will be used to aggregate all discovery of multiple plugin executions inside the same provisioning.xml file. Each execution of the plugin is creating a server configuration (e.g.: standalone.xml, standalone-ha.xml, …) inside the same provisioning.xml file.

For example:

Execution 1 plugin configuration:

<aggregate>wildfly-server</aggregate>
<config-name>standalone-full-ha.xml</config-name>

Execution 2 plugin configuration:

<aggregate>wildfly-server</aggregate>
<config-name>standalone.xml</config-name>

In this example the generated provisioning.xml will be located in the target/wildfly-server-glow/ directory. The server configurations named standalone.xml and standalone-full-ha.xml will be generated and added to the same provisioning.xml file.

4.3. Retrieving the test classes from Maven dependencies

By default the compiled test classes are scanned. In case the classes are coming from Maven dependencies, the dependencies coordinates (groupId:artifactId) can be configured in the plugin. The version being retrieved from the Maven dependencies:

<dependenciesToScan>
    <dependency>org.foo:some-tests</dependency>
</dependenciesToScan>

4.4. Specifying an execution context

By default the bare-metal context is used. In case you need to produce a server to be executed on the cloud, use the <context>cloud</context> element.

4.5. Specifying an execution profile

In case you want to produce an High Available WildFly server, use the <profile>ha</profile> element.

4.6. Using WildFly Preview server

In case you want to use a WildFly Preview server, use the <preview-server>true</preview-server> element.

4.7. Specifying a WildFly server version

By default the latest WildFly server version is used. In case you want to use a specific WildFly version, set the <server-version>server version</server-version> element.

4.8. Using a specific set of Galleon feature-packs

By default the latest WildFly Galleon feature-pack and extra Galleon feature-packs are used. You have the ability to set a list of feature-packs using the <feature-packs> element.

4.9. Understanding which rule selected a given Galleon layer

When setting <verbose>true</verbose>, the set of rules that selected a given layer are printed in the console. Output example:

...
layers inclusion rules
* ee-core-profile-server
  - BASE_LAYER
* ee-concurrency
  - JAVA_TYPE: [jakarta.enterprise.concurrent.*]
* undertow-https
  - ADD_ON
...

4.10. A simple pom.xml file extract

In this extract, the latest WildFly server version is used.

...
<build>
    <plugins>
        <plugin>
            <groupId>org.wildfly.glow</groupId>
            <artifactId>wildfly-glow-arquillian-plugin</artifactId>
            <version>1.0.0.Beta4</version>
            <configuration>
              <expected-discovery>[cdi, ee-concurrency, ee-integration, elytron, messaging-activemq, naming, servlet, undertow]==>ee-core-profile-server,ee-concurrency,messaging-activemq</expected-discovery>
            </configuration>
            <executions>
                <execution>
                    <id>scan</id>
                    <goals>
                        <goal>scan</goal>
                    </goals>
                    <phase>test-compile</phase>
                </execution>
            </executions>
        </plugin>
        <plugin>
            <groupId>org.wildfly.plugins</groupId>
            <artifactId>wildfly-maven-plugin</artifactId>
            <version>5.0.0.Alpha2</version>
            <configuration>
                <overwrite-provisioned-server>true</overwrite-provisioned-server>
                <provisioning-dir>${project.build.directory}/wildfly</provisioning-dir>
                <provisioning-file>${project.build.directory}/glow-scan/provisioning.xml</provisioning-file>
            </configuration>
            <executions>
                <execution>
                    <id>test-provisioning</id>
                    <goals>
                        <goal>provision</goal>
                    </goals>
                    <phase>test-compile</phase>
                </execution>
            </executions>
        </plugin>
    </plugins>
</build>
...

4.11. A custom pom.xml file extract

In this extract, WildFly 30.0.1.Final is used, the ssl add-on is enabled, expected discovery and expected errors are configured. The WildFly Maven Plugin is used to provision the server used by tests.

...
<build>
    <plugins>
        <plugin>
            <groupId>org.wildfly.glow</groupId>
            <artifactId>wildfly-glow-arquillian-plugin</artifactId>
            <version>1.0.0.Alpha12</version>
            <configuration>
                <feature-packs>
                    <feature-pack>
                        <groupId>org.wildfly</groupId>
                        <artifactId>wildfly-galleon-pack</artifactId>
                        <version>30.0.1.Final</version>
                    </feature-pack>
                </feature-packs>
                <add-ons>
                    <add-on>ssl</add-on>
                </add-ons>
                <expected-errors>
                    <error>an add-on of the messaging family is expected by the messaging-activemq layer</error>
                    <error>ambiguous resource injection. Enable verbose output to see the locations.</error>
                    <error>jakarta.naming.Context or InitialContext lookup. Enable verbose output to see the locations.</error>
                </expected-errors>
                <expected-discovery>[cdi, ee-concurrency, ee-integration, elytron, messaging-activemq, naming, servlet, undertow, undertow-https]==>ee-core-profile-server,ee-concurrency,messaging-activemq,undertow-https</expected-discovery>
            </configuration>
            <executions>
                <execution>
                    <id>scan</id>
                    <goals>
                        <goal>scan</goal>
                    </goals>
                    <phase>test-compile</phase>
                </execution>
            </executions>
        </plugin>
        <plugin>
            <groupId>org.wildfly.plugins</groupId>
            <artifactId>wildfly-maven-plugin</artifactId>
            <version>5.0.0.Alpha2</version>
            <configuration>
                <overwrite-provisioned-server>true</overwrite-provisioned-server>
                <provisioning-dir>${project.build.directory}/wildfly</provisioning-dir>
                <provisioning-file>${project.build.directory}/glow-scan/provisioning.xml</provisioning-file>
            </configuration>
            <executions>
                <execution>
                    <id>test-provisioning</id>
                    <goals>
                        <goal>provision</goal>
                    </goals>
                    <phase>test-compile</phase>
                </execution>
            </executions>
        </plugin>
    </plugins>
</build>
...

4.12. Goals overview

help

Prints help for the plugin.

scan

Scan test classes, create deployments and generate provisioning.xml.

4.13. help

4.13.1. wildfly-glow-arquillian:help

Full name: org.wildfly.glow:wildfly-glow-arquillian-plugin:1.2.0.Final:help

4.13.2. Description

Display help information on wildfly-glow-arquillian-plugin.
Call mvn wildfly-glow-arquillian:help -Ddetail=true -Dgoal=<goal-name> to display parameter details.

4.13.3. Attributes

The goal is thread-safe and supports parallel builds.

Table 1. Optional Parameters
Name	Type	Since	Description
`[detail]`	`boolean`	`-`	If `true`, display all settable properties for each goal. Default value is: `false`. User property is: `detail`.
`[goal]`	`String`	`-`	The name of the goal for which to show help. If unspecified, all goals will be displayed. User property is: `goal`.
`[indentSize]`	`int`	`-`	The number of spaces per indentation level, should be positive. Default value is: `2`. User property is: `indentSize`.
`[lineLength]`	`int`	`-`	The maximum length of a display line, should be positive. Default value is: `80`. User property is: `lineLength`.

4.13.4. Parameter Details

detail
If true, display all settable properties for each goal.

Type: boolean
Required: No
User Property: detail
Default: false

goal
The name of the goal for which to show help. If unspecified, all goals will be displayed.

Type: java.lang.String
Required: No
User Property: goal

indentSize
The number of spaces per indentation level, should be positive.

Type: int
Required: No
User Property: indentSize
Default: 2

lineLength
The maximum length of a display line, should be positive.

Type: int
Required: No
User Property: lineLength
Default: 80

4.14. scan

4.14.1. wildfly-glow-arquillian:scan

Full name: org.wildfly.glow:wildfly-glow-arquillian-plugin:1.2.0.Final:scan

4.14.2. Description

(no description)

4.14.3. Attributes

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

Table 2. Optional Parameters
Name	Type	Since	Description
`[addOns]`	`Set`	`-`	Execution add-ons. User property is: `org.wildfly.glow.add-ons`. Alias is: `add-ons`.
`[aggregate]`	`String`	`-`	All executions sharing the same aggregate have their provisioning.xml merged inside a single one. Make sure to have config-name parameter fo each execution sharing the same aggregates. User property is: `org.wildfly.glow.aggregate`. Alias is: `aggregate`.
`[channels]`	`List`	`-`	+ User property is: `org.wildfly.glow.channels`. Alias is: `channels`.
`[checkErrors]`	`boolean`	`-`	By default the execution is aborted when unknown errors are reported. You can disable the check done for errors by setting this option to true. User property is: `org.wildfly.glow.check-errors`. Alias is: `check-errors`.
`[configName]`	`String`	`-`	Server configuration name in the generated provisioning.xml. Default value is: `standalone.xml`. User property is: `org.wildfly.glow.config-name`. Alias is: `config-name`.
`[context]`	`String`	`-`	Execution context, can be `cloud` or `bare-metal`, default value is `bare-metal`, only usable if no `feature-packs` have been set. User property is: `org.wildfly.glow.context`. Alias is: `context`.
`[dependenciesToScan]`	`List`	`-`	GroupId:ArtifactId of dependencies that contain test classes to scan for Arquillian deployments. User property is: `org.wildfly.glow.dependencies-to-scan`. Alias is: `dependencies-to-scan`.
`[expectedDiscovery]`	`String`	`-`	A string identical to what this plugin output. It is used to compare what the plugin has discovered vs what is expected. User property is: `org.wildfly.glow.expected-discovery`. Alias is: `expected-discovery`.
`[expectedErrors]`	`List`	`-`	Expects error to be found by glow (eg: missing datasource, …) that will get fixed by the test. If an error is found and this parameter contains expected errors, the errors are ignored. If no error is found and this parameter contains errors, an exception is thrown. If this parameter is null (the default) and an error is found, an exception is thrown. User property is: `org.wildfly.glow.expected-errors`. Alias is: `expected-errors`.
`[featurePacks]`	`List`	`-`	List of feature-packs that are scanned and injected in the generated provisioning.xml. This option can’t be used when `server-version` or `preview` or `context` are used. Alias is: `feature-packs`.
`[layersForJndi]`	`Set`	`-`	(no description) User property is: `org.wildfly.glow.layers-for-jndi`. Alias is: `add-layers-for-jndi`.
`[previewServer]`	`boolean`	`-`	Use WildFly Preview server, only usable if no `feature-packs` have been set. User property is: `org.wildfly.glow.preview-server`. Alias is: `preview-server`.
`[profile]`	`String`	`-`	Execution profile. User property is: `org.wildfly.glow.profile`. Alias is: `profile`.
`[serverVersion]`	`String`	`-`	A WildFly server version. The latest version is the default, only usable if no `feature-packs` have been set. User property is: `org.wildfly.glow.server-version`. Alias is: `server-version`.
`[skipScanning]`	`boolean`	`-`	Do not lookup deployments to scan. User property is: `org.wildfly.glow.skip-scanning`. Alias is: `skip-scanning`.
`[surefireExecutionForIncludedClasses]`	`String`	`-`	If not specified, it will search all test classes for @Deployment annotated methods. If a surefire execution name is specified, it will only look at test classes picked out by its import/export filters. If set, it will also output the provisioning.xml file in a child folder of that name. Alias is: `surefire-execution-for-included-classes`.
`[systemPropertyVariables]`	`Map`	`-`	System properties to set. For example, you can set org.wildfly.glow.manual.layers system property to a list of layers to add to the discovered set.
`[verbose]`	`boolean`	`-`	Enable verbose output (containing identified errors, suggestions, …). User property is: `org.wildfly.glow.verbose`.

4.14.4. Parameter Details

addOns
Execution add-ons.

Type: java.util.Set
Required: No
User Property: org.wildfly.glow.add-ons
Alias: add-ons

aggregate
All executions sharing the same aggregate have their provisioning.xml merged inside a single one. Make sure to have config-name parameter fo each execution sharing the same aggregates.

Type: java.lang.String
Required: No
User Property: org.wildfly.glow.aggregate
Alias: aggregate

channels

Type: java.util.List
Required: No
User Property: org.wildfly.glow.channels
Alias: channels

checkErrors
By default the execution is aborted when unknown errors are reported. You can disable the check done for errors by setting this option to true.

Type: boolean
Required: No
User Property: org.wildfly.glow.check-errors
Alias: check-errors

configName
Server configuration name in the generated provisioning.xml.

Type: java.lang.String
Required: No
User Property: org.wildfly.glow.config-name
Default: standalone.xml
Alias: config-name

context
Execution context, can be cloud or bare-metal, default value is bare-metal, only usable if no feature-packs have been set.

Type: java.lang.String
Required: No
User Property: org.wildfly.glow.context
Alias: context

dependenciesToScan
GroupId:ArtifactId of dependencies that contain test classes to scan for Arquillian deployments.

Type: java.util.List
Required: No
User Property: org.wildfly.glow.dependencies-to-scan
Alias: dependencies-to-scan

expectedDiscovery
A string identical to what this plugin output. It is used to compare what the plugin has discovered vs what is expected.

Type: java.lang.String
Required: No
User Property: org.wildfly.glow.expected-discovery
Alias: expected-discovery

expectedErrors
Expects error to be found by glow (eg: missing datasource, …) that will get fixed by the test. If an error is found and this parameter contains expected errors, the errors are ignored. If no error is found and this parameter contains errors, an exception is thrown. If this parameter is null (the default) and an error is found, an exception is thrown.

Type: java.util.List
Required: No
User Property: org.wildfly.glow.expected-errors
Alias: expected-errors

featurePacks
List of feature-packs that are scanned and injected in the generated provisioning.xml. This option can’t be used when server-version or preview or context are used.

Type: java.util.List
Required: No
Alias: feature-packs

layersForJndi
(no description)

Type: java.util.Set
Required: No
User Property: org.wildfly.glow.layers-for-jndi
Alias: add-layers-for-jndi

previewServer
Use WildFly Preview server, only usable if no feature-packs have been set.

Type: boolean
Required: No
User Property: org.wildfly.glow.preview-server
Alias: preview-server

profile
Execution profile.

Type: java.lang.String
Required: No
User Property: org.wildfly.glow.profile
Alias: profile

serverVersion
A WildFly server version. The latest version is the default, only usable if no feature-packs have been set.

Type: java.lang.String
Required: No
User Property: org.wildfly.glow.server-version
Alias: server-version

skipScanning
Do not lookup deployments to scan.

Type: boolean
Required: No
User Property: org.wildfly.glow.skip-scanning
Alias: skip-scanning

surefireExecutionForIncludedClasses
If not specified, it will search all test classes for @Deployment annotated methods. If a surefire execution name is specified, it will only look at test classes picked out by its import/export filters. If set, it will also output the provisioning.xml file in a child folder of that name.

Type: java.lang.String
Required: No
Alias: surefire-execution-for-included-classes

systemPropertyVariables
System properties to set. For example, you can set org.wildfly.glow.manual.layers system property to a list of layers to add to the discovered set.

Type: java.util.Map
Required: No

verbose
Enable verbose output (containing identified errors, suggestions, …).

Type: boolean
Required: No
User Property: org.wildfly.glow.verbose

5. Support for latest WildFly

The following documentation is defined by the WildFly Galleon Feature-packs repository. It contains the known WildFly (and WildFly Preview) Feature-packs, Layers and Add-ons for the various execution contexts (cloud and bare-metal).

Known Feature-packs, Layers and Add-ons