This issue should be treated as an epic, with "incorporates" issues used for the concrete work.

Ultimate goal is to be able to specify use of WildFly Channels channels when doing any provisioning used by the testsuite. But, for now at least, using a channel would be optional. Code overhead to allow the two cases should be kept to the minimum.

Steps:

1) WFLY-18790 Convert testsuite provisioning from galleon-maven-plugin to wildfly-maven-plugin.

2) WFLY-18791 As part of the build create a channel artifact for each feature pack. Currently not deployed, as the scope of this JIRA is testing. But the artifact should be made available locally to the maven reactor.

3) WFLY-18792 Add a property-driven profile where if the property is set -Dwildfly-channels=<the_value> is included in the wildfly-maven-plugin launch. This allows complete external control of the channel.

4) WFLY-18793 Add a property-driven profile where if the property is set the 'wildfly-channels' value to pass to the wildfly-maven-plugin is calculated based on the current reactor settings (e.g. use the gav of the channel produced in step 2).

5) WFLY-18794 Add per PR or nightly test jobs as appropriate to test channel based provisioning.

6) WFLY-18839 Work out a technique for controlling client side dependencies in the test suite based on what the channel specifies.

7) WFLY-19221 Use the wildly-maven-plugin and the channel produced in #2 to produce the 'official' installations in the build and dist modules. (This step is not required for the test coverage goal of this epic, as the jboss.inst variable supports pointing the testsuite at a channel-provisioned WildFly installation.)

Separate work can be done for specific tests related channel-based provisioning behavior. That work may rely on some of the steps above (e.g. having a channel avaiable in the reactor), but it's not part of the scope of this JIRA. An example of such testing is tests needed for WFCORE-6560.