anchor.diff:  Currently next await strategies are supported:
   
   native:: it uses *wait* command. In this case current thread is waiting until the _Docker_ server notifies that has started. In case of foreground services this is not the approach to be used.
  -polling:: in this case a polling (with _ping_ or _ss_ command) is executed for 5 seconds against all exposed ports. When communication to all exposed ports is acknowledged, the container is considered to be up. This approach is the one to be used in case of services started in foreground. By default _polling_ executes _ss_ command inside the running container to know if the server is already running. You can use a _ping_ from client by setting +type+ attribute to +ping+; Note that _ping_ only works if you are running _Docker_ daemon on +localhost+. In almost all cases the default behaviour matches all scenarios.
  +polling:: in this case a polling (with _ping_ or _ss_ command) is executed for 5 seconds against all exposed ports. When communication to all exposed ports is acknowledged, the container is considered to be up. This approach is the one to be used in case of services started in foreground. By default _polling_ executes _ss_ command inside the running container to know if the server is already running. You can use a _ping_ from client by setting +type+ attribute to +ping+; Note that _ping_ only works if you are running _Docker_ daemon on +localhost+. In almost all cases the default behaviour matches all scenarios. If it is not specified, this is the default strategy.
   static:: similar to _polling_ but it uses the host ip and specified list of ports provided as configuration parameter. This can be used in case of using _Boot2Docker_.
   sleeping:: sleeps current thread for the specified amount of time. You can specify the time in seconds or milliseconds.
   
  
positive.code: |dockerContainersFile
  |Instead of embedding YAML string, you can set YAML file location in this attribute. This location can be a relative location from root of the project or also a URI that is converted to URL so you can effectively have docker definitions on remote sites. 
  
  |autoStartContainers
  |Cube will normally only start a _Docker_ container when it has the same name as an active _Arquillian_ container. That works for things that are _DeployableContainer_'s. For any other service, e.g. a database, you can use the _autoStartContainers_ option to define which _Docker_ containers to automatically start up. The option takes a comma separated list of _Docker_ container ids. e.g. _tomcat7, mysql_. *Arquillian Cube* will attempt to start the containers in parallel if possible as well as start any linked containers.
  
  
negative.code: CMD ["/tomcat/bin/catalina.sh","run"]
  ----
  <1> +tomcat-users.xml+ file is located at same directory as +Dockerfile+.
  
  [[docker-compose-format]]
  == Docker-Compose Format
  
  Instead of using Arquillian Cube format, you can use Docker Compose format to define containers layout. This means that you can use the same Docker Compose file for running your tests with Arquillian Cube and without any change run `docker-compose up` command from terminal and get the same result.
  
  It is important to note that this is not a docker-compose implementation but only the docker-compose format. This means that for example you cannot execute some CLI commands of _docker-compose_ like start several instances of same service.
  
  In case of some specific Arquillian Cube attributes like await strategy cannot be configured and the default values are going to be used.
  
  Moreover there are some docker-compose commands that are not implemented yet due to restrictions on docker-java library. These commands are _label_, _pid_, _domainname_, _log_driver_, _security_opt_ and _read_only_. But they will be implemented as soon as docker-java library adds their support.
  
  Last thing, in case you define a command that is not implemented in Arquillian Cube, this command will be ignored (no exception will be thrown), but a log line will be printed notifying this situation. Please it is really important that if this happens you open a bug so we can add support for them. Althought this warning we will try to maintain aligned with the latest docker-compose format.
  
  Let's see how you can rewrite previous HelloWorld example with Tomcat to be used using docker-compose format.
  
  First let's create a file called `envs` on root of the project which configures environment variables:
  
  [source]
  .envs
  ----
  TOMCAT_PASS=mypass
  JAVA_OPTS=-Djava.rmi.server.hostname=localhost -Dcom.sun.management.jmxremote.rmi.port=8088 -Dcom.sun.management.jmxremote.port=8089 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false
  ----
  
  Then you can create a file called `docker-compose.yml` following docker-compose commands on root of the project:
  
  [source, yml]
  .docker-compose.yml
  ----
  tomcat:
    env_file: envs
    image: tutum/tomcat:7.0
    ports:
        - "8089:8089"
        - "8088:8088"
        - "8081:8080"
  ----
  
  and finally you can configure in `arquillian.xml` file that you want to use docker-compose format.
  
  [source, xml]
  .src/test/resources/arquillian.xml
  ----
  <extension qualifier="docker">
    <property name="serverVersion">1.13</property>
    <property name="serverUri">localhost</property>
    <property name="definitionFormat">COMPOSE</property>
    <property name="dockerContainersFile">docker-compose.yml</property>
  </extension>
  
  <container qualifier="tomcat">
    <configuration>
      <property name="host">${docker.tomcat.host}</property>
      <property name="httpPort">8081</property>
      <property name="user">admin</property>
      <property name="pass">mypass</property>
    </configuration>
  </container>
  ----
  
  And that's all, you can now reuse your existing docker-compose files in Arquillian Cube too. 
  You can see the full example at: https://github.com/arquillian/arquillian-cube/tree/master/docker/ftest-docker-compose
  
  == Enrichers
  
  