Problems installing Groovy-Eclipse extension in SpringSource Tool Suite 2.7.1

Attempting to install the Groovy-Eclipse extension in STS 2.7.1, I received obscure error messages about a conflicting dependency with a Maven extension.  Using a new workspace did not fix the problem.  When trying with STS 2.8.1, I received a much better error message:  that I could not install since STS was in the C:\Program Files directory.  To verify this, I moved my STS program directory to the root of C: and tried to install the Groovy-Eclipse extension again:  No problems this time.

Comparing against some of my other computers with STS and the Groovy-Eclipse extension installed, it appears that the Groovy-Eclipse extension does not like the space character in C:\Program Files.

Third-party JARs and Nexus

The Nexus documentation (start here and Uploading Artifacts) is quite good for what to do to deal with third-party JARs and basically JARs that don't reside in any repository out in the rest of the world (obsolete versions or proprietary).  However, if you aren't careful, the Nexus user interface can be misleading.  For the Artifact Upload interface, it can be easy to select the POM file and select the JAR artifact, but neglect to press the Add Artifact button.

Nexus will then simply upload the POM file but not the JAR file.  At this point, the clean-up of the mess begins.

Your Maven build will fail, not being able to locate the JAR file.  If you attempt to re-do the step, but this time, pressing the Add Artifact button, you will get the following error:

You need to clean up the repository of the Nexus server, which you can do by going to the Browse Storage tab > navigating to the appropriate section by GAV > right-click > Delete. 

 However, if you attempt another build, Maven will fail again.  If you look at the build log, you will see something like:

Failure to find ... in http://.../nexus/content/groups/public was cached in the local repository, resolution will not be reattempted until the update interval of nexus has elapsed or updates are forced

The next step is to go to the Local repository where the Maven build ran and clean it up.  Navigate in the file system by GAV and you will find files named similarly to:

some-artifact-0.1.jar.lastUpdated

some-artifact-0.1.pom.lastUpdated

Delete these, re-run the Maven build.  It should find your artifacts now.

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)

You Are not the User

Read Ask "What Would the User Do?" (You Are not the User) last week or so.  My thoughts on the article:

• It is always better to have a prototype, on paper or a digital mockup, of the user interface so that a user can work through it, rather than a verbose "user interface requirements" document
• As developers, although we usually are able to figure out new user interfaces we encounter, we often do the same things novice users do especially when things don't work as expected.  E.g. once we figure out a user interface, we may do the same steps all the time instead of looking for a short-cut.  And sometimes we stick with the same tools or older versions because we find it too much of a learning curve to try new ones

97 Things

Making time to read one article everyday from 97 Things Every Programmer Should Know (book format or online) and write about it the following day or soon after.  Advice I've read so far:

• "Act with Prudence" - one way (not perfect) to keep track of technical debt is to use TODOs in the code.  The text associated with a TODO should be specific enough so that someone else reading it in the context of the code understands what still needs to be done.  
• "Apply Functional Programming Principles" - (a) indeed, as the author Edward Garson states, mis-use of object-oriented programming creates bad designs.  In particular, IMO, the difference between using setters versus parameters to a method is not entirely clear.  The advent of Spring also has popularized the use of setters although Spring can just as easily work with constructors so that when an object is instantiated, its state is correct and it is ready to be used.  My rule of thumb is when in doubt, use parameters to a method to pass arguments, not with setters.  (b) As the author also states, test-driven design also helps to promote better design.  IMO it is because as you write automated test cases, you become a user of your API ("Eating your own dog food" principle), and you begin to understand what makes an API easier/cleaner to program against.