Using the Wildfly Channel manifest file to override the module version in provisioned WildFly server.

I have added a jberet-manifest module into the JBeret project this week:

• Add jberet-manifest by liweinan · Pull Request #427 · jberet/jsr352

The above PR shows the usage how to wrap a manifest file into a module, and how to use it in the wildfly-maven-plugin to override the module version used in the provisioned WildFly server. The format of the manifest file is defined in this project:

• WildFly Channel

The manifest file can be generated by tool or can be handwritten. In the above PR, the file is handwritten:

• jberet-manifest/src/main/resources/jberet-channel-manifest.yaml

And you don’t have to include all the component versions used in WildFly server, and you can only specify the component version you want to override.

Otherwise, the file can also be generated by the Galleon Provisioning tool:

• https://github.com/wildfly/galleon

Which I won’t extend the usage of this tool in this blog post. But if you are interested in how to use the tool to generate the manifest file, this branch can be used for reference:

• Comparing resteasy:main…jamezp:channel-manifest · resteasy/resteasy

Which contains the usage of the plugin:

<plugin>
    <groupId>org.wildfly.galleon-plugins</groupId>
    <artifactId>wildfly-galleon-maven-plugin</artifactId>
    <executions>
        <execution>
            <id>resteasy-galleon-feature-pack</id>
            <goals>
                <goal>build-feature-pack</goal>
            </goals>
            <phase>prepare-package</phase>
            <configuration>
                <fork-embedded>${galleon.fork.embedded}</fork-embedded>
                <generate-channel-manifest>true</generate-channel-manifest>
                <add-feature-packs-as-required-manifests>false</add-feature-packs-as-required-manifests>
            </configuration>
        </execution>
    </executions>
</plugin>

As the code shown above, the generate-channel-manifest option of the plugin can be used to generate the manifest file.

So after we have the manifest file, we can use it in the wildfly-maven-plugin:

• channels configuration

As you can see the built manifest will be used in provision:

<channels>
    <channel>
        <manifest>
            <groupId>org.jberet</groupId>
            <artifactId>jberet-channel-manifest</artifactId>
            <version>${project.version}</version>
        </manifest>
    </channel>
</channels>

And in the provisioned WildFly server directory we can see the module is override according to the configuration:

➤ pwd
/Users/weli/works/jsr352/test-deployment/target/wildfly/modules

➤ find . | grep jberet
./system/layers/base/org/wildfly/extension/batch/jberet
./system/layers/base/org/wildfly/extension/batch/jberet/main
./system/layers/base/org/wildfly/extension/batch/jberet/main/wildfly-batch-jberet-30.0.1.Final.jar
./system/layers/base/org/wildfly/extension/batch/jberet/main/module.xml
./system/layers/base/org/jberet
./system/layers/base/org/jberet/jberet-core
./system/layers/base/org/jberet/jberet-core/main
./system/layers/base/org/jberet/jberet-core/main/jberet-core-2.2.0-SNAPSHOT.jar
./system/layers/base/org/jberet/jberet-core/main/module.xml

You can see the jberet-core-2.2.0-SNAPSHOT.jar is the module overridden by the manifest.

I’d like to thank these people provides me help on this:

• jamezp - Overview
• jfdenise - Overview
• bstansberry - Overview

• 上一篇 Some Learning Materials About The Java Multi-Release JAR Feature
• 下一篇 Playing with the WildFly Quickstart `batch-processing` example