The current deploy() method looks for xml contributions in the current classpath. First one hence wins. To be sure which resource is actually loaded it led everyone to override basic xml configuration that doesn't need to in their integration JUnit tests.

Here are the use cases NXRuntimeTestCase should implement (summary of discussion with Bogdan S)

     - deploy a whole jar with its OSGI-INF configuration: typical for an integration test: we want e.g, the schema service to be available in the same way it is in the application. Maybe follow dependencies, here, or at least *loudly* stop in case some are missing
     - control which jars are actually deployed: we might have a dependency to core packages to get an interface/class and still not want to construct a full Nuxeo Core instance
     - override the configuration that sits in the jar (we could use test/resources as an equivalent to /config in nuxeo.ear, but this has to stay manual). Typical use-case: fake ram repository,
     - true unit tests can go on using
     - I don't think we need to load test resources from a jar in dependencies: we've always used separated *-test packages for generic helpers; they can provide resources for their test clients in src/main/resources

A good deal of the problems with non nxruntime resources (schemas etc) can be solved, I guess, by the fact that they would be now deployed where they are defined, as normal (non test) resources, if one deploys the whole jar that usually defines them.