[wildfly-dev] Wildfly provisioning tools and packaging format

[Stuart Douglas]

Just so everyone is aware these build/provisioning tools now live at

https://github.com/wildfly/wildfly-build-tools

with JIRA at

https://issues.jboss.org/browse/WFBUILD

Stuart

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
> 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
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev