Spock and Roo - Maven's conventions step in to mess with me

Ok, here's a cautionary tale.

I had everything working just fine in one project using Spock - on Jenkins builds I was getting code coverage working. It was great!

Hey, listen, keep this in mind:

src/test/java is NOT src/main/groovy! Now my jQuery project is starting to use code coverage - go ahead and view the report...

Oh, and one more thing: bind them to test-compile, not test. AAAHH!

:)

Ok, here's my maven build fragment for running the tests (I assume now that the file set is no longer needed...)

<plugin>
    <groupId>org.codehaus.gmaven</groupId>
    <artifactId>gmaven-plugin</artifactId>
    <version>1.4</version>
    <configuration>
        <providerSelection>1.8</providerSelection>
    </configuration>
    <executions>
        <execution>
			<id>test-run</id>
            <goals>
				<goal>generateTestStubs</goal>
                <goal>testCompile</goal>
            </goals>
			<phase>test-compile</phase>
			<configuration>
				<sources>								
						<fileSet>
							<directory>src/test/groovy</directory>
							<includes>
								<include>**/*.groovy</include>
							</includes>
						</fileSet>							
				</sources>
			</configuration>						
        </execution>
    </executions>
    <dependencies>
        <dependency>
            <groupId>org.codehaus.gmaven.runtime</groupId>
            <artifactId>gmaven-runtime-1.7</artifactId>
            <version>1.3</version>
            <exclusions>
                <exclusion>
                    <groupId>org.codehaus.groovy</groupId>
                    <artifactId>groovy-all</artifactId>
                </exclusion>
            </exclusions>
        </dependency>
        <dependency>
            <groupId>org.codehaus.groovy</groupId>
            <artifactId>groovy-all</artifactId>
            <version>1.8.6</version>
        </dependency>
        <dependency>
            <groupId>org.spockframework</groupId>
            <artifactId>spock-core</artifactId>
            <version>0.6-groovy-1.8</version>
        </dependency>
        <dependency>
            <groupId>org.spockframework</groupId>
            <artifactId>spock-spring</artifactId>
            <version>0.6-groovy-1.8</version>
        </dependency>
    </dependencies>
</plugin>

Maven Search Site Online

I was a bit surprised to find out about this, but in teaching a couple of Maven courses two weeks ago, I did my usual "and you can go to the Maven Central repository at repo1.maven.org/maven2" - but things changed on me...

For years (since the inception of Maven), when you browsed that repository URL, you'd get a file listing of the entire repository, which you could drill down into manually.  Wanna see what's in commons-lang/commons-lang/2.6?  Just click away.  However, there was no search.  In fact, there were two search URLs that I knew of (and more I'm sure) - such as mvnrepository.com and repository.sonatype.org (I think, that URL is offline now).

It looks like Nexus is powering the Maven central repo now, and also they've put a message up at that central URL:

Browsing for this directory has been disabled.

View this directory's contents on http://search.maven.org instead.

Huh.  Ok, so I'll bite...  If you go to the http://search.maven.org site, you'll see a nice search engine.  I typed in commons-lang, and lo and behold, there is a 3.0 version too.  Click on the image below to see the whole screen capture, if you're curious.

Uploaded with Skitch!

I'm glad they did this. The Nexus repository gives useful reports on dependencies, and provides the mounting code for a number of dependency managers, including Maven, Ivy, Buildr, and more. A nice touch. By the way, the new URL to remember is http://search.maven.org!

My Maven doesn't build Codehaus anymore, what's wrong?

Recently Codehaus moved artifacts to the nexus repository system, and added a 302 MOVED directive to every request to the OLD repository. (See HAUS-1991).

But, Maven can't deal with this (I haven't tested this assumption in Maven 3.0.0, but it certainly fails in 2.x)

So, if you have:

• a) Maven
• b) a Codehaus plugin or artifact

and you try to build, you MAY get this error:

[INFO] Error building POM (may not be this project's POM).

Project ID: org.codehaus.mojo:jboss-packaging-maven-plugin

Reason: Error getting POM for 'org.codehaus.mojo:jboss-packaging-maven-plugin' from the repository: Unable to read local copy of metadata: Cannot read metadata from '/Users/krimple/.m2/repository/org/codehaus/mojo/jboss-packaging-maven-plugin/maven-metadata-codehaus.xml': end tag name  must match start tag name 
 from line 7 (position: TEXT seen ...\n... @9:8) 
  org.codehaus.mojo:jboss-packaging-maven-plugin:pom:LATEST

So, how do you fix it?

Semi-easy. First, replace any reference to the codehaus repos with these, as documented in the link to HAUS-1991 above:

• Deploy snapshot artifacts into repository https://nexus.codehaus.org/content/repositories/snapshots
• Deploy release artifacts into the staging repository https://nexus.codehaus.org/service/local/staging/deploy/maven2
• Promote staged artifacts into repository 'Releases'
• Download snapshot and release artifacts from group https://nexus.codehaus.org/content/groups/public
• Download snapshot, release and staged artifacts from staging group https://nexus.codehaus.org/content/groups/staging

Then you will have to delete the files that maven complains about in the .m2 directory - they'll be ones like org/codehaus/mojo/jboss-packaging-maven-plugin/maven-metadata-codehaus.xml - that contain the errant HTML document that sends a redirect header.

Do a mvn package again and you'll be set.

HTH, Ken

Kickin' Butt with Spring Roo at the command line with Maven shade plugin

Note: I just noticed, maybe it's something just added in 1.1.0 or later builds, but they have the assembly plugin integrated with the Roo Shell perform command. So you can do perform assembly and actually get an assembled jar with all dependencies. WOOT. Anyway, this is still useful for those who want to run Maven headless projects.Let's say you want to use Spring Roo to do persistence work, but you don't need a website. Maybe it's just a utility, something that, say uses iText to generate PDF files, or does some data processing, job execution, or some other headless task.

Spring Roo is built using Maven, and the build target generally start in an initial Roo project by deploying a JAR file, until you add Spring MVC by adding a controller. In Maven, the output of a given build is generally one thing, (the jar) so running the project might involve downloading a ton of JAR files to add to a very big classpath. That's a lot of work.

Alternatives - Maven Packaging Plugins

There are a number of maven packaging plugins that can assemble a Jar that includes all of your classes and property files from various source Jars. Several, including the Maven assembly plugin, and the one-jar plugin, didn't work for me out of the gate due to some problems loading some of the SpringSource XML schemas and extender languages.

The challenge is that these special files, META-INF/spring.handlers and META-INF/spring.schemas, are included in each of the extension JARs (like Spring Security, Spring MVC, JMS, etc) so that you can issue commands like this:

<mvc:annotation-driven />

These tools generally copy files into a temp directory and then jar it up, so they overwrite these files each time.

The Shade Plugin

The Maven shade plugin has a nice feature called a transformer. There is a special AppendingTransformer class that can be configured to continue to append data into a file specified in the configuration. Based on this article from Hagel Blog, I added two entries to the plugin configuration (as commented below) to fix the two META-INF files and we were in business.

So, without further adieu, here are the steps to single-jar happiness (at least so far) with Spring Roo and the Maven Shade plugin:

Step 1: Install the Shade Plugin to your pom.xml file

Using your STS or favorite editor, go to your maven build file, pom.xml, and add the following entry to the build -> plugins section (THANK YOU, Hagel Blog, for figuring out the problem with Spring's namespace files!):

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-shade-plugin</artifactId>
  <version>1.3.3</version>
  <executions>
    <execution>
      <phase>package</phase>
      <goals>
        <goal>shade</goal>
      </goals>
    </execution>
  </executions>
  <configuration>
      <transformers>      
      <transformer implementation="org.apache.maven.plugins.shade.
             resource.AppendingTransformer">
        <resource>META-INF/spring.handlers</resource>
      </transformer>
      <transformer implementation="org.apache.maven.plugins.shade.
             resource.AppendingTransformer">
        <resource>META-INF/spring.schemas</resource>
      </transformer>
    </transformers>
  </configuration>
</plugin>

Step 2: Run your maven build

Now you can just issue a mvn package command, which will package up your content in the JAR file directly.

Step 3: Execute your JAR

Go ahead now and cd to target, and issue a command like:

java -classpath ./artifact-jar-file-name.jar package.path.and.mainclassname

And that's it. Pretty nifty feature, no? Let me know if you've had success or problems with this approach.