Tracking branches:

proposal A: http://github.com/mojavelinux/arquillian/tree/ARQ-287-proposalA
proposal B: http://github.com/mojavelinux/arquillian/tree/ARQ-287-proposalB

In both proposals, the include/exclude surefire configuration has been completely replaces with a required execution environment annotation on each test class. Note, however, that this feature only works for JUnit until we get support in TestNG to veto the test (currently a work in progress).

Both proposals are based on @ProvidedBy which is a hard coding of package name expressions for the given Containers. This approach does not scale at all. If at all, this should be moved down to the Container.

But then the issues becomes, who am i(the container dev) to force no support for CDI in JBoss 5. Someone might have hacked it up.. The users knowns better then we do what the containers he is running against supports.

This approach also makes the api 'dependent' on technology related terms like EJB, EE, CDI, etc.. (technology come and go, arquillian is here to stay..

A much simpler approach would be to let the user define some sort of group names that make sense to him and his test suite, where he could add filtering of the groups e.g. in arquillian.xml pr Container.

e.g.

@Group("Messaging-BackendSystem-1-Test")
@RunWith(Arquillian.class)
public test MyTest() {}

arquillian.xml:

<jboss:container id="messaging-backend">
<group>Messaging-BackendSystem-1-Test</group>
..
</jboss:container>

<jboss:container id="messaging-front">
<group>Messaging-FrontendSystem-1-Test</group>
..
</jboss:container>

Note: multiple containers of the same type can be added, but represent different things to the user. All EE6 tests are not necessarily fit for all configured EE servers.

Please review the formal proposal: https://community.jboss.org/message/561676

I want to repeat my note here that I strongly oppose doing any of this in XML-based configuration. I want the information about what the test requires in the test class. I am open, however, to considering other ways in which containers are linked to execution environments. Though we want to avoid annotation scanning or burdening the developer w/ configuration.

Btw, I disagree that the design proposed does not scale. The built-in environments are merely a convenience. Developers have the option of combining ExecutionEnvironment and @ProvidedBy to define a custom execution environment. It's totally extensible.

For instance, some of the Arquillian JUnit examples can only be run on JBoss AS, so we define it as an execution environment:

@ProvidedBy(
   containers =
  

)
public final class JBossAS6Container implements ExecutionEnvironment {}

There is no reason why the developer can't come up with any combination they need. I'm just not all the comfortable with how we are referencing containers. I'd like that to be a cleaner association. Perhaps to be discussed in a seperate JIRA, i'd like to have containers declare a unique identifier, the common name, the vendor and the supported version range.

by scale I mean, we need arquillian-api changes every time a container/enricher is added/changed/removed..