9:32 p.m.
Paul Gier [http://community.jboss.org/people/pgier] modified the document:
"JBoss Modules Surefire Plugin"
To view the document, visit: http://community.jboss.org/docs/DOC-16240
--------------------------------------------------------------
This is a fork of org.apache.maven.plugins:maven-surefire-plugin:2.6:test which allows you
to run tests using modular classloading provided by jboss-modules. The source for this
plugin is available in github ( https://github.com/kabir/jboss-modules-surefire-plugin
https://github.com/kabir/jboss-modules-surefire-plugin)
h4. Configuration
It has the configuration options of the 'real' surefire plugin (
http://maven.apache.org/plugins/maven-surefire-plugin/test-mojo.html
http://maven.apache.org/plugins/maven-surefire-plugin/test-mojo.html), although your
mileage may vary if you start playing with the fork modes. The plugin takes a module
definition file and creates a directory structure containing modules in the jboss-modules
format
It has the configuration options of the
http://maven.apache.org/plugins/maven-surefire-plugin/test-mojo.html original surefire
plugin, although your mileage may vary if you start playing with the fork modes. The
plugin takes a module definition file and creates a directory structure containing modules
in the jboss-modules format.
For the forked module there are some more options for configuring the modules:
*roots:*
Points to a list of exisiting module root directories, such as jboss-as7/modules
* *Type:* java.io.File[]
* *Required:* No
*cleanModulesDirectory:*
If true (default) clean out the modules directory created by the plugin each time we run
the tests.
* *Type:* boolean
* *Required:* No
* *Expression:* ${jboss.modules.clean}
* *Default:* true
*modulesDirectory:*
The absolute path of the modules output directory created from +*moduleDefinitionFile*+
* *Type:* java.io.File
* *Required:* No
* *Expression:* ${jboss.modules.directory}
* *Default:* ${project.build.directory}/modules
*logModule:*
The name of the -logmodule parameter passed in to JBoss Modules (i.e. the name of the
module containg the jboss logmanager). This is needed if the target project uses
java.util.Logging or jboss logging, and the jboss log manager is not on the system
classpath.
* *Type:* java.lang.String
* *Required:* No
* *Expression:* ${jboss.modules.logmodule}
*logConfiguration:*
The JBoss logging configuration if any. This must be set if the target project uses jboss
logging and you want any output to be displayed
* *Type:* java.io.File
* *Required:* No
* *Expression:* ${logging.configuration}
*moduleDefinitionFile:*
The path of the module definition file.
* Type java.io.File
* Required: Yes
* Expression: ${jboss.modules.definition}
* Default: ${project.build.testOutputDirectory}/modules/module-def.xml
In addition, when using jboss logging you will need to set the following system properties
in your pom when using this plugin (full example later):
<systemProperties>
<property>
<name>java.util.logging.manager</name>
<value>org.jboss.logmanager.LogManager</value>
</property>
<property>
<name>jboss.home.dir</name>
<value>${jboss.home}</value>
</property>
<property>
<name>org.jboss.boot.log.file</name>
<value>${jboss.home}/standalone/log/boot.log</value>
</property>
</systemProperties>
*h4. Module Definition File
*
This sets up the modules used for running your tests, which are then copied to
*+modulesDirectory+* from the plugin settings. The plugin automatically sets up a module
called +jboss.surefire.module+ for you which contains the plugin classes, junit and your
project's target/classes and target/test-classes directories. If you want to set up
more modules you can define those in the *+moduleDefinitionFile+*. The schema is very
simple, and rather than duplicating the work done by jboss-modules the validation of most
of the stuff is delegated to jboss-modules when loading the modules. Here is an example:
<?xml version="1.0" encoding="UTF-8"?>
<modules xmlns="urn:jboss:surefire-module:1.0"
targetNs="urn:jboss:module:1.0">
<test-module-dependencies>
<module name="org.jboss.as.standalone"/>
<module name="org.jboss.modules"/>
<module name="org.jboss.threads"/>
<module name="my.test.module"/>
</test-module-dependencies>
<module name="my.test.module">
<resources>
<resource-root path="$some.group:some-artifact$"/>
</resources>
</module>
</modules>
+targetNs+ is the schema of the targetted jboss-modules version.
+test-module-dependencies+ adds the listed dependencies to the +jboss.surefire.module+
module directly into the dependencies section of the created module. In this case we
follow the jboss-modules 1.0 schema. In this case the
+modulesDirectory+/jboss/surefire/module/main/module.xml looks like:
<?xml version="1.0" encoding="UTF-8"?>
<module name="jboss.surefire.module"
xmlns="urn:jboss:module:1.0">
<main-class name="org.apache.maven.surefire.booter.SurefireBooter"/>
<resources>
<resource-root path="surefire-api-2.6.jar"/>
<resource-root path="surefire-booter-1.0.0.Alpha1.jar"/>
<resource-root path="junit-4.8.1.jar"/>
<resource-root path="test-classes"/>
</resources>
<dependencies>
<module name="org.jboss.as.standalone"/>
<module name="org.jboss.modules"/>
<module name="org.jboss.threads"/>
<module name="org.jboss.threads"/>
</dependencies>
</module>
You can have as many +modules/module entries as you like and they just get copied across.
The $some.group:some.artifact$+ value gets resolved from your project's dependencies
into the path to that dependency in your local maven repository. In this case (assuming
your pom has a dependency on some.group:some-artifact:1.3.0, which then gets copied from
the local maven repository to the module directory)
+modulesDirectory+/my/test/module/main/module.xml looks like:
<?xml version="1.0" encoding="UTF-8"?>
<module name="my.test.module" xmlns="urn:jboss:module:1.0">
<resources>
<resource-root path="some-artifact-1.3.0.jar'/>
</resources>
</module>
h4. Consuming the plugin from a pom
Normally you want to turn off the normal surefire plugin since that does not understand
modular classloading
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.6</version>
<!-- Disable the standard surefire plugin since that runs tests without
modular classloading -->
<configuration>
<skipTests>true</skipTests>
</configuration>
</plugin>
Then enable and configure the jboss modules surefire plugin (${jboss.home} is configured
elsewhere in the pom and points to a built JBoss AS 7 instance)
<plugin>
<groupId>org.jboss.maven.surefire.modular</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>1.0.0.Alpha1</version>
<executions>
<execution>
<goals>
<goal>test</goal>
</goals>
</execution>
</executions>
<configuration>
<!-- standard surefire options -->
<redirectTestOutputToFile>true</redirectTestOutputToFile>
<enableAssertions>true</enableAssertions>
<systemProperties>
<property>
<name>java.util.logging.manager</name>
<value>org.jboss.logmanager.LogManager</value>
</property>
<property>
<name>jboss.home.dir</name>
<value>${jboss.home}</value>
</property>
<property>
<name>org.jboss.boot.log.file</name>
<value>${jboss.home}/standalone/log/boot.log</value>
</property>
</systemProperties>
<includes>
<include>org/jboss/as/test/surefire/**/*TestCase.java</include>
</includes>
<!-- Extra forked plugin options -->
<logModule>org.jboss.logmanager</logModule>
<logConfiguration>${jboss.home}/standalone/configuration/logging.properties</logConfiguration>
<roots>
<root>${jboss.home}/modules</root>
</roots>
</configuration>
</plugin>
h4. Coming up (after Christmas)
* Will investigate if surefire report works with this or if that needs forking too
* Integrate this plugin with the JBoss AS 7 Arquillian container so that the Arquillian
test runner is booted up in a modular classloader. This should enable us to get rid of the
current workarounds
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-16240]
Create a new document in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&am...]