- 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).

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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev