I've reworked the demos so they can be run as part of our testsuite: https://github.com/kabir/jboss-as/tree/demos-test-modules
This is not a pull request, there are still a few small issues that need looking at, just want to get your feedback/suggestions.
I first tried using the flat application classpath to do this. With some small modifications I was able to get an embedded instance to run in vm and to be able to connect to it via the standalone client. Those changes were changing how ServerControllerOperationHandler initializes its marshaller and how extensions are initialzed. However, trying the sar example I never saw the MBean get started, which is probably due to the sar deployer adding dependencies on some modules. David suggested adding/replacing these modules with something else to be able to make them use the system classpath.
What I have now is quite similar to how the protocol tests worked. Under testsuite/modular we have these projects
-common/ contains the test interfaces, e.g. DemosTest, and has nothing on the classpath
-impl/ contains the real tests, e,g. DemosTestImpl which implements DemostTest, and has everything it needs to build on the classpath
-assembly/ creates the test modules (more about this later)
-test/ contains the tests run, e.g. DemosTestCase which delegates to DemosTestImpl via the DemosTest interface. It sets up the module loader roots and loads its test via the module loader.
This way when running the tests only jboss-modules, testsuite/module/common and junit are on the classpath.
The module roots used are:
1) build/target/jboss-xxx/stanalone/modules - for the stanard AS modules
2) assembly/target/modules - assembly creates modules for maven artifacts which don't exist in 1) and which are only available as maven dependencies, so they can't be constructed in 3).
3) test/target/module_roots - These are modules created from other classes in the workspace, and are configured via annotations on the test interface from common/, e.g.:
@TestModules({
@TestModule(
moduleName="test.demos",
packages={@TestModulePackage(packages={"org.jboss.test.as.modular.impl.demos", "org.jboss.test.as.modular.impl"})},
dependencies= {"demos.archive", "org.jboss.as.messaging", "javax.jms.api"}),
@TestModule(
moduleName="demos.archive",
jars=@TestModuleJar (project="demos", jar="jboss-as-demos.*(?<!sources)\\.jar"),
dependencies= {"org.jboss.as.standalone-client", "org.jboss.as.testsuite.modular.shrinkwrap", "javaee.api", "org.jboss.as.protocol", "org.hornetq"}),
@TestModule (
moduleName="test.demos.tccl",
dependencies= {"org.jboss.as.testsuite.modular.shrinkwrap", "org.jboss.logging", "demos.archive"},
includeSystem=false)
}
)
@TestSetup(
implClass="org.jboss.test.as.modular.impl.demos.DemosTestImpl",
testModule="test.demos",
tcclModule="test.demos.tccl")
public interface DemosTest extends ModularTest {
void testSar() throws Exception;
void testManagedBean() throws Exception;
...
}
This creates three modules:
-test.demo - which is created from classes in those packages in the impl/ project
-demos.archive - which is created from the examples we had in the demos/ project
-test.demos.tccl - which is the modules that need to be part of the TCCL for ShrinkWrap to work. I've worked around https://jira.jboss.org/browse/MODULES-55 for now.
So the main thing is that while this works fine, setting up a test using modular classloading isn't exactly trivial. If someone has some ideas for how to programatically import maven dependencies we could get rid of assembly at least. But we would still have three parts per test. I'll look into creating a custom junit runner tomorrow, which might make the overall setup simpler.
If we go with something like this, should my final goal be Arquillian integration?
If the protocol tests get redone they should be moved into this framework.