anchor.diff:  
   . Let's deploy our common library. We can do this by using the JBoss CLI.
   +
  - $EAP_HOME/bin/jboss-cli.sh -c "deploy common-utils/target/common-utils-1.0.jar"
  + $JBOSS_HOME/bin/jboss-cli.sh -c "deploy common-utils/target/common-utils-1.0.jar"
   
   . Verify that the deployment was successful:
   +
   ----
  -$EAP_HOME/bin/jboss-cli.sh -c deployment-info
  +$JBOSS_HOME/bin/jboss-cli.sh -c deployment-info
   NAME                 RUNTIME-NAME         PERSISTENT ENABLED STATUS               
   common-utils-1.0.jar common-utils-1.0.jar true       true    OK   
   ----
  
positive.code: find . -name module.xml | xargs grep -L property | sort
  ====
  
  == Application depends on custom static module
  Since joda-time is unsupported, we should deploy our own module--that we will maintain--and depend on it instead. In fact, it is a good practice to create and maintain any static modules you may need, so you can upgrade with less risk. This applies to most third-party modules. However, if an application depends on container-provided functionality, like JBoss Logging, it should depend on the JBoss-provided module.
  
  . Let's upgrade our dependency on joda-time to the latest version (`2.4` at the time of this writing). That way we can use new features, such as `MonthDay`. Change the version of joda-time in the `pom.xml` to 2.4. Leave the scope as `provided`.
  +
  [source,xml]
  .pom.xml
  
negative.code: +
  As you can see, even though JBoss contains a module for joda-time, JBoss uses the version included in the WAR since no dependency is declared on the static module.
  
  TIP: TODO: Show module logging here
  
  == Application depends on static module provided by JBoss
  
  . Change the scope of the joda-time maven dependency to `provided`.
  +
  