[dan.j.allen]

Okay, I think I've got it straight in my head.

I think that you are correct in that we have two selection requirements:

1. Qualifiers - these distinguish between two or more distinct instances of a configuration (in CDI, this would be a @Qualifier)
2. Profiles - these distinguish between mutually exclusive options (in CDI, this would be an @Alternative)

So far, we've been using qualifiers for containers as alternatives and qualifiers for extensions as qualifiers. We need to get this straightened out.

Also, in the configuration, I think we should separate activation of containers and extensions so that we aren't mixing two concerns.

In the case that there is no ambiguity (meaning no alternatives), then no activation is required. Arquillian should just select what is requested in the test (speaking of qualifiers).

In the case there are two possible choices (such as two configurations of JBoss AS 7.1 remote), then one is the default and the other has to be explicitly activated.

Here's an example of how a configuration might look with both qualifiers and profiles:

<arquillian>
   <container id="jbossas-remote-7.1">
   ...
   </container>
   <container id="jbossas-remote-7.1" profile="dev">
   ...
   </container>
   <container id="jbossas-remote-7.1" profile="qa">
   ...
   </container>
   <container id="jbossas-remote-7.1" profile="ci-saucelabs">
   ...
   </container>

   <extension id="webdriver">
       <property name="browser">firefox</property>
   </extension>

   <extension id="webdriver" qualifier="UserB">
       <property name="browser">firefox</property>
   </extension>

   <extension id="webdriver" qualifier="UserB" profile="ie">
       <property name="browser">ie</property>
   </extension>
</arquillian>

* A container or extension element w/o a profile is the default, unless another default is specified explicitly.

Now let's say we want to run the tests in a Win32 SauceLabs environment.

arquillian-activation.properties

activate.container.qualifiers=ci-saucelabs
activate.extension.qualifiers=ie

Does that work?

[dan.j.allen]

I'm also noticing that the way we do qualifiers in the code is different for extensions and containers.

In containers, we do:

@TargetsContainer("containerA")

In extensions, we do:

@Drone @UserB WebDriver driver;

First, I think type-safety is the way to go, so I like the approach being used for extensions. However, I like to avoid stacking annotations, so perhaps we can follow the approach used for JUnit categories.

@TargetsContainer(ContainerA.class)
@Drone(UserB.class)

That won't break @Drone currently, but that will break compabilitilty for @TargetsContainer. One way to avoid that is to use an explicit attribute (which makes it more clear anyway).

@TargetsContainer(qualifier = ContainerA.class)
@Drone(qualifier = UserB.class)

wdyt?

[dan.j.allen]

With the configuration nodes so specific, we may violate DRY. Therefore, I think it's a good idea to support an "inherits" configuration option.

<container id="jboss-as-remote-7.1">
    ...
</container>
<container id="jboss-as-remote-7.1" profile="qa" inherits="DEFAULT">
    <!-- properties here override properties in parent -->
</container>
<container id="jboss-as-remote-7.1" profile="ci" inherits="qa">
   <!-- properties here override properties in parent -->
</container>

In this case, inherit references profiles. I'm not sure if we also need to support inherits for qualified entries. Either way, we can think of other ways to represent the link to the parent, but that's the general idea.

[dan.j.allen]

I left out an example of qualifiers on containers. Let's assume the tests are working with two containers.

<arquillian>
   <container id="jbossas-remote-7.1" qualifier="containera">
   ...
   </container>
   <container id="jbossas-remote-7.1" qualifier="containerb">
   ...
   </container>
   <container id="jbossas-remote-7.1" qualifier="containera" profile="qa">
   ...
   </container>
   <container id="jbossas-remote-7.1" qualifier="containerb" profile="qa">
   ...
   </container>
</arquillian>

(If we use annotations for qualifiers in code, then the qualifier value in the XML can be written as the simple name of the class, lowercased)...or we can add hypens at the camelcase junctions (like spring).

If I want to run the tests in qa, then I would use arquillian-activation.properties (or a system property, of course)

arquillian-activation.properties

active.container.profile=qa

However, I just realized that for multi-node control, we already have a group element for that purpose. So actually, the XML would be like this:

<group>
   <container id="jbossas-remote-7.1" qualifier="containera">
   ...
   </container>
   <container id="jbossas-remote-7.1" qualifier="containerb">
   ...
   </container>
</group>
<group profile="qa">
   <container id="jbossas-remote-7.1" qualifier="containera">
   ...
   </container>
   <container id="jbossas-remote-7.1" qualifier="containerb">
   ...
   </container>
</group>

Still the same activation.

[dan.j.allen]

Keep in mind that the id element is import. It is entirely responsible for associating a configuration with an adapter. There is no ambiguity here anymore. The only time the tester has to use arquillian-activation.properties is when there are two choices for the same adapter*.

* Even then, I think there is room for auto-activation. For instance, if the hostname of the computer begins with "qa", then an Arquillian extension could automatically switch to that profile. Profile selection should be an extension point!

[dan.j.allen]

https://issues.jboss.org/browse/ARQ-1216