I've taken a better look at your solution now, and we are taking two opposite approaches.
Most of my work was done before Brian pointed out to me that the -Djava.class.path system property has influence on what is visible to the module system. In my case I am making sure everything runs in modules, both the test itself and the server. This might be overkill and forces a lot of definition of modules etc. which although made simple to set up will still probably be confusing to users new to module classloading.
In your case the server is started up using modules with the classpath and with the test itself and its dependencies using the app classpath, the -Djava.class.path system property controls that the app classpath is not visible to the server. I will look more into your solution now, but what you have is a lot simpler to set for the user so I think we should go with something based on that. I would still like a hook in Arquillian to be able to set tccl before starting it so that your logging abstraction is not necessary.
For now I would say that 'Dependencies' does exist and gets processed by the DUP, but we should not promote its usage by introducing an annotation for it. How about requiring the user to explicitly put it in the @Deployment artifact manifest like I do in ModuleAccessesBundleServiceTestCase
private JavaArchive getClientModuleArchive() throws Exception
{
final JavaArchive archive = ShrinkWrap.create(JavaArchive.class, "example-xservice-client-module");
archive.addClasses(EchoInvokerService.class, ClientModuleActivator.class);
String activatorPath = "META-INF/services/" + ServiceActivator.class.getName();
archive.addResource(getResourceFile("xservice/client-module/" + activatorPath), activatorPath);
archive.setManifest(getResourceFile("xservice/client-module/" + JarFile.MANIFEST_NAME));
return archive;
}
This is something I was already doing for the demos. I don't really like it though, I think it would be nicer to be able to specify this somehow from within the test itself rather than having loads of manifest files in the resources but we can talk about that later.