Arquillian.xml alternative format

When you need to configure something in Arquillian you use arquillian.xml. For example in case to configure the webdriver in Drone/Graphene you do something like:

 <extension qualifier="webdriver">
        <property name="browser">${browser}</property>

I ask myself could we do the same but with .properties? So for example the same example could be rewiriten to:


or in case of containers:

<container qualifier="container1" default="true">
      <property name="tomcatHome">target/tomcat-embedded-6-standby</property>
      <property name="workDir">work</property>

can be expressed as:


You may wonder why I am suggesting this change too. Well my first idea is to give people the opportunity to choose xml or .properties. But after that there is another idea. And it is that you can configure/override values using system properties for example:

-Darquillian.container.container1.default=true -Darquillian.container.container1.configuration.workDir=work

In this way we are going to support setting system properties natively, so no more hacks with Maven which is a different hack from Gradle and different from Ant. In this way for example in you Jenkins you will be able to set properties directly. And of course also we can extend this to environment variables as well so you can inject the configuration inside a Docker container using Dockerfile.


This is already implemented

You can override/add any arquillian.xml value via System properties

Or provide a file as an alternative (name could be overriden via

1 Like

Great!!1 I haven’t seen this, is it possible is not documented? Well now it is time to enhance chpater 2 of the book with this addition :smile:

1 Like

Inspecting the code I have seen that you are running System.getProperties() which are java system properties can we add also that system environment variables plays a game too? I asked this because nowadays with Docker it is really an extended way to populate configuration parameters. I can provide a PR if you agree.

Sure, that sounds good.

What should be the override order?

SysProps override Env override XML ?

I think it should be Env -override-> SysProps (-D…) -override-> -override-> arquillian.xml

I think Env should be the one who overrides everything since in case of Docker it will be the only way to modify parameters. So if developer internally overrides using sys props, then Docker developer will not be able to modify them.


Hi, when you are speaking about the different ways of configuration - I was thinking if it would be possible to configure Arquillian via fluent API in java (using ArquillianDescriptor class).
Same as we have the method annotated with @Deployment for deployment creation, there could be also a method for creating arquillian.xml.:

public static ArquillianDescriptor createArquillianXml()
    return new ArquillianDescriptorImpl().defaultProtocol("Servlet 3.0").extension("webdriver").property("browser","firefox");


I haven’t spent much time with investigating this feature, but I guess that the main problem is that the configuration is loaded to early (before the test class itself is observed). Have you anyone think about this feature?

Exactly, this is the main problem but since it is an static method maybe we could intercept it when test class is available in context and reconfigure something. But of course I am not sure we will be able to reconfigure everything or only some parts.

As Alex points out, arquillian.xml is not tied to the TestClass level, but the Suite level. So it would be odd to have ArqXml Descriptor and a Deployment in the same class as you could have multiple combinations.

Possible solutions would be:

  • Treat each Class as a Suite


  • Scan for a ArqXml Desc in ‘some class’ and fail if multiple found
  • Define a sys prop that refer to the Class to scan

But on a more general note; Why would you want that?

  • More control over how arq.xml is constructed?
  • What’s the current limitations?

The approach:

[quote=“aslak, post:9, topic:206”]
Scan for a ArqXml Desc in ‘some class’ and fail if multiple found
[/quote] seems to be as the best one.

And why would I want to do that? Me personally - I don’t need it, but some guys, I was talking to, they would appreciate it.

The possible use-cases:

  • There would be the possibility to postpone the decision what to set into arq.xml until the runtime. Eg. based on some condition, that is accessible during the runtime.
  • If there is some more complex process of creating eg. jboss.home path
  • Do some stuff (copy the whole jboss directory, modify a container) before creating arq.xml

…so, yeah - “More control over how arq.xml is constructed” is the reason

Regarding the current limitation - there is no limitation right now. We can use maven properties, maven plugins, filters, docker files, scripts, etc… and do all the stuff I’ve written above. However, I can imagine that in some cases this can be really messy, and have everything written in java - in one Java project - is sometimes more tidy and more transparent…

Continuing the discussion from Arquillian.xml alternative format:

Is there any way to find out what the final setting looks like? I mean from the test class? When you take into account the whole overriding hierarchy and default values, it can be really hard to figure out what is the last final state of the setting.

I am not sure if they are logged, but if @aslak agrees it could be a good improvement.

Some extension do this already, like the Recorder will print it’s configuration.

The problem from Cores perspective is it can only print the content of the Arq config chain at ‘some point’ . Most logical point would be after we’ve done all the sys props / env / xml parsing/overloading, but that’s not to say ‘some’ extension couldn’t come in and change that later.

Regardless of that, an option to print the config sounds like a good idea.

Yes in fact Recorder uses System.out for this.