[wildfly-dev] Wildfly provisioning tools and packaging format

[Stuart Douglas]

Hi all,

So now that the core split has happened, I want to start work on the new 
tooling for creating Wildfly feature packs.

At the moment the build is using a simple maven plugin that I created, 
that will take an existing server (e.g. the core server), layer some 
extra modules over the top of it, build the config files, and perform 
any other build tasks that are required. It can also turn a 'thin' 
server into a traditional fat server.

This is going to change to having two separate tools, the build tool and 
the provisioning tool. The build tool will be used to create Wildfly 
feature packs. A feature pack is kinda similar to what is already 
produced, but with some major differences:

- It does not contain the contents of any feature packs it was built on. 
For example at the moment the results of web-build also contains the 
server core. The web-build feature pack will only contain modules 
provided by the web-build pack.

- It is not a server, in that it cannot just be unzipped and ran, the 
provisioning tool must be used first to create a runnable server from a 
set of feature packs.

Once the build tool has created the feature packs, it is then up to the 
provisioning tool to use them to assemble a working server. The 
provision tool will be written as a library, with multiple front ends. 
At the very least we will provide a standalone version and a maven plugin.

The provisioning tool takes a server descriptor, and uses that to 
download all the relevant feature packs and assemble them into a server. 
This process will give the user a lot of flexibility over how the server 
is configured, including:

- The ability to specify only the subsystems they are after, and a cut 
down subsystem with just these subsystems and their dependents will be 
installed.
- The ability to override versions, e.g. to provision a server with an 
updated version of Resteasy.
- The ability to install deployments into the server by specifying the 
deployments GAV.
- The ability to customise the default config (not sure how this will 
work yet. A yuck solution would be xslt, but no one likes that. A nicer 
solution could be some kind of CLI script that is run on first boot).

This provisioning tool will also be used to build our server for our 
traditional distribution and test suite. Basically as part of the build 
process the maven plugin will be run to provision a server from the 
constituent feature packs.

The feature pack layout will look like below:

------

versions.properties
wildfly-pack.xml
modules/
    com/acme/mymodule
                   module.xml
    ...
repository (optional)
      com/acme/myartifact/my-artifact.jar
      ...
configuration
    standalone.xml
    standalone-full.xml
    domain.xml
    ...
content
    bin/README.txt
    bin/LICENSE.txt
    ...
------
The contents of these files and directories is as follows:

versions.properties - properties file with the format G:A(:C)=V, e.g. 
org.jboss.resteasy:resteasy-jaxrs=3.0.0.Final
wildfly-pack.xml - This contains all additional pack metadata:
    pack name: The name of the feature pack, must not contain spaces
    pack description: Self explanatory
    packaging version: This is inferred from the schema
    required tool version: The minimum version of the provisioning tool 
that is required to handle this pack
    permissions: A section to set unix file permissions
    version overrides: A section that allows for specific overrides of 
versions in the base system
    dependencies: Information on the feature packs this pack depends on

modules:
Similar to the modules dir we have today, with some exceptions:
- only artifact references are used, and these artifacts just refer to 
group and artifact, without the version number. See the modules.xml 
files in the current build for an example.

repository:
   Contains maven artifacts in the maven repository layout. This allows 
for the creation of 'offline' feature packs, where the pack
   does not need access to an external maven repository. This is not 
required, and in most cases will not be used.
   I am not 100% sure if we actually want this.

configuration:
   contains configuration template files, e.g. standalone.xml template

content:
   anything in this directory will be copied directly into the server

Comments? It is expected that work will be started on this tooling very 
shortly to replace the current build plugin. I am going to create a 
wildfly-build-tools repository to hold these new plugins.

Stuart