Getting Groovy test cases to run with Maven

Groovy is excellent for writing test cases because of its brevity and meta-programming capabilities.  For example, a class that I was using to do integration testing called System.exit in its main method.  With Groovy I could re-define its main method so that I could continue running the rest of my test code:

        Launcher.metaClass.'static'.main = { String[] args ->
            delegate.programArguments = args
            delegate.init()
            delegate.run()
            // No more System.exit!
        }

However, to get Groovy test cases to run inside Maven (and outside of Eclipse) requires some tweaks.  First of all, you have to make Maven aware that there are Groovy test cases to execute, or else it won't even find them  The section "Configuring Maven2 to compile and run your Groovy tests" in the article Writing unit tests using Groovy is mostly correct but it is out-of-date.  If you use its Maven coordinates verbatim, you will have errors in your Maven output.

Error:  Execution default of goal org.codehaus.mojo.groovy:groovy-maven-plugin:1.0-beta-3:testCompile failed: An API incompatibility was encountered while executing org.codehaus.mojo.groovy:groovy-maven-plugin:1.0-beta-3:testCompile: java.lang.NoSuchMethodError: org.codehaus.plexus.PlexusContainer.hasChildContainer(Ljava/lang/String;)Z
This can be corrected by changing the coordinates of the Groovy Maven plugin to:              
<groupId>org.codehaus.mojo</groupId>
<artifactId>groovy-maven-plugin</artifactId>
<version>1.3</version>

Error:  Failed to execute goal org.codehaus.mojo:groovy-maven-plugin:1.3:testCompile ... Unknown type: METHOD_DEF
This can be caused by anonymous inner classes in the code.  Groovy for Java Programmers gives some suggestions for how to re-format your code so that Groovy can properly parse it and recognize an anonymous inner class definition, however these suggestions didn't work for me.  Anonymous inner class are a convenience so one can re-write the code to eliminate them.

Error:  initializationError(...): [Lorg/codehaus/groovy/runtime/callsite/CallSite;
You may only see one line in the Maven output which is not particularly helpful.  However, you can look at the detailed test output.  In Hudson, it would be at a location under HUDSON_HOME similar to jobs\<your job>\workspace\target\surefire-reports\  Looking here, you may see an error java.lang.NoClassDefFoundError: [Lorg/codehaus/groovy/runtime/callsite/CallSite;
To fix this, update your Groovy Maven run-time coordinates to:

<groupId>org.codehaus.groovy.maven.runtime</groupId>
<artifactId>gmaven-runtime-1.6</artifactId>
<version>1.0</version>
<scope>test</scope>

After all this, you should finally see your Groovy test executed in the Maven output.

Maven install:install-file output is misleading?

Using Apache Maven 3.0.3 (r1075438), Maven will report "BUILD SUCCESS" even when the file argument points to a non-existent file (e.g. mvn install:install-file -Dfile=C:\temp\jmockit.jar ...).  Naturally, this can lead to some confusion when your source code still refuses to compile.

XPath heaven and Namespace hell

XPath is fairly easy to learn by example (great examples here) but namespaces in the XML can be maddening when they cause data to be alluded.  Some things to check before you resort to using simple string matching or regular expressions to get to your XML data:

• XPath expressions are case-sensitive
• Indexing is 1-based rather than 0-based, e.g. /MSG.2[1] refers to the first element (not the second element)
• Default namespaces (e.g. xmlns="urn:hl7-org:v3" vs. xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance", the former having a default namespace) requires that you set up a prefix for the namespace if you want to write XPath expressions against the XML content.  Good article about default namespaces 
• When writing XPath expressions where namespaces are involved, you need to prefix each element in the expression (with the appropriate namespace prefix).  E.g. /hl7v3:PRPM_IN301030CA/hl7v3:controlActEvent/hl7v3:effectiveTime is required, /hl7v3:PRPM_IN301030CA/controlActEvent/effectiveTime will not work (there is no inheritance down the branch)