[
https://issues.jboss.org/browse/ARQ-1216?page=com.atlassian.jira.plugin.s...
]
John Ament commented on ARQ-1216:
---------------------------------
Most important - you should avoid breaking what currently works on developers/testers.
This will ease migration to the new way. Everything old can be marked as deprecated, and
only drive new features in to the new setup. *Do not break the old setup.*
The first issue that needs to be addressed is why you can only have one container on the
classpath at a time. I'm assuming there is some marker interface that Arquillian uses
to determine this is a container (probably the local implementation of LoadableExtension
that's in every container).
Once that's done, couldn't you start by adding some new tags to arquillian.xml,
allowing the selection of which container to run and set each of these with an ID? Then
setup some kind of JVM argument or something indicating which arquillian test set to run
based on these IDs? Then make sure it allows you to run multiple (either serial or
parallel). Maybe..
mvn test -DarquillianContainer=weld_ee -DarquillianContainer=jbossas_managed_7
I would almost argue that these need to be two different issues, one covering containers
and the other covering extensions (though they are essentially both extensions...)
More intelligent and flexible container and extension configuration
-------------------------------------------------------------------
Key: ARQ-1216
URL:
https://issues.jboss.org/browse/ARQ-1216
Project: Arquillian
Issue Type: Enhancement
Security Level: Public(Everyone can see)
Components: Configuration, Deployable Containers SPI
Reporter: Dan Allen
Story:
*In order to* make activating or selecting container configuration easier
*As a* tester
*I want to* be able to use ids, profiles and qualifiers in the configuration so
Arquillian can automatically select the correct configuration in most cases
Scenarios:
*Given* that I specify an id in the container configuration
*When* I use a container adapter
*Then* Arquillian should be able to activate that configuration by matching the globally
unique id for that container with the id of the container configuration
*Given* that I define multiple container configurations with the same id, each with
unique profile attributes
: *And* I define the property active.container.profile in
arquillian-activation.properties with a value equal to one of the profiles
*When* I run the test
*Then* Arquillian should select the container configuration for the profile that I
activated
*Given* specify a qualifier at a @Drone injection point
: *And* I include a webdriver extension configuration with a qualifier attribute whose
value matches the qualifier at the injection point
*When* I run the test
*Then* Arquillian Drone should select the extension configuration that uses that
qualifier
Rationale:
First and foremost, container adapters should have globally unique ids. This allows
Arquillian to be able to link a container configuration to the adapter in use
automatically by matching the container adapter id with the id attribute on the container
configuration node.
If there are multiple configurations for the same adapter, then the configurations must
each have a unique profile attribute value (excluding the profile attribute implies a
default value).
Therefore, it's only necessary to activate a container configuration when there are
multiple configurations for the same adapter and you don't want to use the default
selection.
The default selection is either the container configuration which specifies
default="true" or, if one is not explicitly marked, the container configuration
without a profile attribute. If neither is the case, then an initialization error should
be thrown.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:
http://www.atlassian.com/software/jira