[wildfly-dev] Wildfly provisioning tools and packaging format
sdouglas at redhat.com
Thu Jul 3 12:24:37 EDT 2014
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
- 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
- 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:
The contents of these files and directories is as follows:
versions.properties - properties file with the format G:A(:C)=V, e.g.
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
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.
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.
contains configuration template files, e.g. standalone.xml template
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.
More information about the wildfly-dev