5 Replies Latest reply on Sep 6, 2012 7:03 AM by Aslak Knutsen

    Simplification of Arquillian Drone configuration

    Karel Piwko Master

      For a long time, we are trying to improve user experience while configuring Drones in Arquillian.

      Let me go through the steps what we have done till Drone 1.0.0 went out:


      1/ Arquillian.xml configuration was given <extension qualifier="extension_name"> tags

      2/ Arquillian Drone split the configuration into various extensions like "webdriver", "selenium", "selenium-server", "graphene"

      3/ Arquillian Drone had added a support for type safe qualifiers which map directly to the configuration so you can have


      @Drone @MySuperbDrone WebDriver drone;


      configured via


      <extension qualifier="webdriver-mysuperbdrone">
         <property name="fooBarProperty">...</property>


      4/ Arquillian Drone added a system property mapping, so the previous can be specified as "-Darquillian.webdriver.mysuperbdrone.foo.bar.property=..." as well


      Although these steps made Drone super flexible, it was still something difficult for usage, especially with WebDrivers, which required him to use "implementationClass" property. In 1.1.0.x, we added a new concept of browserCapabilities, which roughly map to DesiredCapabilities and we added a possibility to add capabilities as well, so you could do the following:


      <extension qualifier="webdriver">
        <property name="browserCapabilities">chrome</property>
        <property name="capabilityChromeSwitches">--data-dir=/tmp</property>


      Although this is nice, it is too complicated. For instance, you have to know that capabilityChromeSwitches maps to chrome.switches capability of ChromeDriver and can be overrided with system property named arquillian.webdriver.capability.chrome.switches. That camel case mapping is a pita and ARQ-1064 was just a top of iceberg. Having a possibility to map any property to any map is nice, however it only complicates things.



      Even if we are currently in 1.1.0.CR2, I propose following configuration simplifications, which are already implemented and available for review at https://github.com/arquillian/arquillian-extension-drone/pull/19

      • Deprecate camel sense tricky-stuff
      • Allow any characters in property name
      • Allow any characters in sysproperty key name
      • Map all unknown properties as capabilities (that actually means stored in all Map<String,String>s in the configuration class)
      • Preserve all former property in deprecated mode and drop them in Drone 2.0.0


      How would this work?


      <extension qualifier="webdriver">
        <property name="browserCapabilities">chrome</property>
        <property name="chrome.switches">--data-dir=/tmp</property>


      The sysproperty key would be arquillian.webdriver.browserCapabilities, the old one still works but emits a warning:


      12:05:31.412 WARN: The system property "browser.capabilities" used in Arquillian "webdriver" configuration is deprecated, please rather use new format "browserCapabilities"


      The same happens if user uses old configuration:


      10:58:11.843 WARN - The property "chromeBinary" used in Arquillian "webdriver" configuration is deprecated.

      10:58:11.843 WARN - Configuration property "chromeBinary" is deprecated, please replace it with capability based property "chrome.binary" instead.


      For some of legacy properties, additional warning might be emited as well:


      10:58:11.843 WARN - The property "operaQuit" used in Arquillian "webdriver" configuration is deprecated.

      10:58:11.843 WARN - Configuration property "operaQuit" is deprecated, please replace it with capability based property "opera.no_quit" instead.

      10:58:11.843 WARN - "operaQuit" value was negated and stored as "opera.no_quit" capability


      User would be finally allowed to use all the capabilities of browsers without Drone impl being updated, like ones with underscope, dash or mixed uppercase/lowercase. Moreover, he won't be disrupted by a different properties in Drone and plain WebDriver. He would no longer have to remap properties by looking in Drone docs.


      Obviously, Drone keeps some of the properties, which does not have a capability equivalent, like chromeDriverBinary or remoteAddress. These prefer new sysproperty notation as well, so arquillian.webdriver.chromeDriverBinary instead of arquillian.webdriver.chrome.driver.binary, but as said previously, legacy configuration still works, it is complaining verbosely though.


      Moving former stuff to legacy module have following advantages:

      • Simplifies all Factories, which does not have to longer move configuration field values into capabilities
      • Simplifies/deprecates a lot of TypedWebDriverConfiguration, which is the most scarying class in whole Drone
      • Simplifes ConfigurationMapper
      • Shows how better SPI would be handy


      What would be the next step? Implement proper SPI event model, to make this mappers extensible. This is out of scope of Arquillian Drone 1.1.0.Final though, sorry Lukas .


      What do you think about these changes? Do you like them or not?