Arquillian.xml alternative format

lordofthejars · July 22, 2015, 1:29pm

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>
 </extension>

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

arquillian.extension.webdriver.browser=safari

or in case of containers:

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

can be expressed as:

arquillian.container.container1.default=true
arquillian.container.container1.configuration.tomcatHome=target/tomcat...
arquillian.container.container1.configuration.workDir=work

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.

WDYT?

aslak · July 23, 2015, 12:17am

This is already implemented

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

github.com

arquillian/arquillian-core/blob/master/config/impl-base/src/main/java/org/jboss/arquillian/config/impl/extension/PropertiesParser.java

/*
 * JBoss, Home of Professional Open Source
 * Copyright 2011 Red Hat Inc. and/or its affiliates and other contributors
 * as indicated by the @authors tag. All rights reserved.
 * See the copyright.txt in the distribution for a
 * full listing of individual contributors.
 *
 * Licensed under the Apache License, Version 2.0 (the "License");
 * you may not use this file except in compliance with the License.
 * You may obtain a copy of the License at
 * http://www.apache.org/licenses/LICENSE-2.0
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 */
package org.jboss.arquillian.config.impl.extension;

import java.util.HashSet;

This file has been truncated. show original

github.com

arquillian/arquillian-core/blob/master/config/impl-base/src/test/java/org/jboss/arquillian/config/impl/extension/ArquillianDescriptorPropertiesTestCase.java

/*
 * JBoss, Home of Professional Open Source
 * Copyright 2010 Red Hat Inc. and/or its affiliates and other contributors
 * by the @authors tag. See the copyright.txt in the distribution for a
 * full listing of individual contributors.
 *
 * Licensed under the Apache License, Version 2.0 (the "License");
 * you may not use this file except in compliance with the License.
 * You may obtain a copy of the License at
 * http://www.apache.org/licenses/LICENSE-2.0
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 */
package org.jboss.arquillian.config.impl.extension;

import java.io.ByteArrayInputStream;
import java.io.IOException;

This file has been truncated. show original

Or provide a arquillian.properties file as an alternative (name could be overriden via -Darquillian.properties=x):

github.com

arquillian/arquillian-core/blob/master/config/impl-base/src/main/java/org/jboss/arquillian/config/impl/extension/ConfigurationRegistrar.java

/*
 * JBoss, Home of Professional Open Source
 * Copyright 2010 Red Hat Inc. and/or its affiliates and other contributors
 * by the @authors tag. See the copyright.txt in the distribution for a
 * full listing of individual contributors.
 *
 * Licensed under the Apache License, Version 2.0 (the "License");
 * you may not use this file except in compliance with the License.
 * You may obtain a copy of the License at
 * http://www.apache.org/licenses/LICENSE-2.0
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 */
package org.jboss.arquillian.config.impl.extension;

import java.io.InputStream;
import java.util.Map;

This file has been truncated. show original

lordofthejars · July 23, 2015, 8:17am

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

lordofthejars · July 24, 2015, 8:36pm

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.

aslak · July 27, 2015, 12:12am

Sure, that sounds good.

What should be the override order?

SysProps override Env override XML ?

lordofthejars · July 27, 2015, 8:13am

I think it should be Env -override-> SysProps (-D…) -override->arquillian.properties -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.

Alex.

mjobanek · July 27, 2015, 8:20am

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.:


@ArquillianXml
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?

lordofthejars · July 27, 2015, 8:39am

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.

aslak · July 27, 2015, 3:18pm

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

or

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?

mjobanek · July 28, 2015, 11:51am

Hi,
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…

mjobanek · July 28, 2015, 12:02pm

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.

lordofthejars · July 28, 2015, 1:34pm

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

aslak · July 28, 2015, 4:22pm

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.

lordofthejars · July 28, 2015, 4:34pm

Yes in fact Recorder uses System.out for this.