Integration tests, multiple containers, multiple API implementations and Maven. Any tips?

How would you go about configuring the following in Maven? Assume I have 4 modules:

• data-access-api
• data-access-impl-derby
• data-access-impl-postgresql
• data-access-integration-tests

Assume I want to be able to test against two containers:

• arquillian-jbossas-ebedded-6
• arquillian-glassfish-embedded-3.1

To run my integration tests, I need the 'data-access-api' module and exactly one of the implementations. I also want to test against exactly one of the containers. I can think of a few ways of making it work, but they all have drawbacks and I don't even know if Maven supports some of them.

I found the following suggestion to add the concept of profile groups to Maven, but, as far as I can tell, nothing similar has ever been added:

http://docs.codehaus.org/display/MAVENUSER/Improvements+to+Profile+Activation+Deactivation

The concept of having a group of mutually exclusive profiles would work, but could get unmanageable fairly quickly. Imagine 3 implementations and 3 containers. There would be 9 possible profile configurations even though I may only be interested in testing 3 or 4 of the possible combinations.

Another solution I can think of is to create one integration module for each scenario that needs to be tested. For example (verbose name to clarify what I mean):

• integration-arquillian-glassfish-embedded-data-access-postgresql

However, I can't figure out a way to do that without duplicating my integration tests. My data-access-integration-tests module has only integration tests. I use CDI for dependency injection and the tests run against the API. I can run the same set of tests against each implementation. It's just a matter of packagi开发者_JAVA技巧ng exactly one implementation with the API.

I'm using Maven 2 for now.

What about putting your integration tests into an abstract class and into a separate module (what you already did) and create an derived class which creates the instance of the implementation and execute those tests. That would solve first to implement the tests only once, cause you're testing implementations against your interface behavior. May be this makes it a little bit clearer. I would say the last thing you suggested would be the best so your "integration-arquillian-glassfish-embedded-data-access-postgresql" will contain only a single class which derives from your abstract class and create the particular instance and run the tests.