[wildfly-dev] Wildfly provisioning tools and packaging format
stuart.w.douglas at gmail.com
Mon Sep 1 01:24:49 EDT 2014
Just so everyone is aware these build/provisioning tools now live at
with JIRA at
Stuart Douglas wrote:
> 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
> - 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:
> repository (optional)
> 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.
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
More information about the wildfly-dev