Cutting Edge Development


Good morning my loyal readers (both of you)! Since this is a brand new blog I can address all of my readers by first and last name, include their home address and still have plenty of room left for the real reason I'm posting this morning. I'll begin by explaining that I've been having lots of fun lately with two relatively new technologies, Maven2 and Groovy. The problem is in getting them to work together. These are two open source projects with heavy activity. They both provide lots of innovation in the world of Java development. For those of you who are not heavily involved with programming, I'll elaborate some.

Maven2, a sequel or rewrite of the original Maven application, is a build system; a technology used to manage the compilation, packaging, and delivery or your programming project. Java developers are familiar with Ant, a similar technology which happens to be the defacto standard for managing a Java based project. Comparing Maven to Ant would be like comparing the Lego starship to a random collection of Lego blocks respectively. Maven is a build system including everything you need to compile package and distribute your project out of the box whereas Ant is a collection of build tools including everything you need to create your own custom build system out of the box. The main reason to consider Maven is freedom from developing and maintaining your build system. Many Java developers spend a good deal of time programming the build system. Almost as much time as they spend programming the application that the build system is intended for. The nice fellows of the Maven2 project are happy to assume that responsibility and that makes Maven2 the ideal project for your programmer in a rush to get the project out the door.

Groovy is a new Java scripting language. Java scripting languages (not to be confused with Javascript which is also a Java scripting language) run within the Java Virtual Machine and do not need to be compiled so they are best for rapid prototyping. That's not a good reason to look at Groovy, though. After all there has been a number of scripting languages introduced to Java over the years and they all have pros and cons. Groovy appears to offer a solid set of all around features that cover the pros offered by most of the available scripting language. It's a best of all breeds programming language. I'll itemize a few features. Groovy can be interpreted or compiled so that you can use it for quick and dirty stuff as well as production projects that require the speed of compiled code. Groovy syntax is a superset of Java syntax so it can be written like traditional Java or mixed with Groovy special syntax features. Speaking of features, Groovy supports some of the most sought after egg-headed syntactic features in programming such as closures, the ability to create DSLs (Domain Specific Languages) and static and dynamic typing. You really have to be a devoted programmer to appreciate what that means.

Now I've gone off on a tangent somewhat. My intent is not to give a sales pitch on two different technologies. My intent is to expound on what I've done with them. So far that amounts to nothing. So why am I wasting your time and mine? Well 've done a little more than nothing actually. I've managed to get the two technologies to cooperate with each other. That is an important step because, from my understanding, both communities (the Groovy camp and the Maven2 camp) are unaware of what each other is doing. That is, there isn't a lot of knowledge shared between the developers of both projects. So I felt it was up to me to bridge the gap between the islands. That's where my story began. Finally we get to the meat of today's post so without further ado I'll stuff in the contents of one of my frequent emails on the Groovy project's mailing list. See below:

[Begin email snip]

Well I finally settled on what I felt was a good
combination for starting a new project, Maven. So I dove in face first
trying to code, TDD style, a component that would allow me to write, test,
and modify XSL stylesheets (since I can't purchase a good XSL editor I have to hack stuff like this). That's what started things.

Day One…
I downloaded and installed the latest version of Eclipse, and tried to install
the Groovy plugin following the instructions on the Groovy site. Well, at the
time there was a couple of minor build errors in the plugin so I contacted
Guilluame directly who replied immediately with the help I needed. Being new
to both the Language and the community I found this refreshing and
encouraging. I then installed toyed with a recently installed copy of M2 and
followed the directions on the Maven site. I was able to create a project
using the Java archetype with one command:

mvn archetype:create -DgroupId=com.mycomp.dataformat -DartifactId=Data-Format

Cool! I then decided to open my project with Eclipse (this is where things got
a little hairy since I'm rusty with Eclipse). I found a docs explaining
Maven2 Eclipse integration and had a fairly easy job getting a Maven Eclipse
project defined.

mvn eclipse:eclipse

That did the trick, and I was able to run the command directly out of Eclipse
after I set a mvn variable pointing to the mvn executable. I wrote my first
Groovy unit test intentional programming style against a class that didn't
exist. I created it under the stubbed package under the src/test/java folder.
I then created an empty definition of the nonexistant class in another groovy
script under the src/main/java folder and here's where my things got thick. I
naturally wanted to run the test to see it fail and I didn't know how. (I
still don't know how.) Well that took me on a journey learning more about
Groovy, Eclipse, and Maven2. I first decided that since there was no groovy
archetype (an archetype is a project template) in M2 I would treat the Java
archetype as a groovy project. In other words I would treat my groovy files
as Java source since they all compile to the same bytecode anyway. That would
keep me outta defining plugins and tech-specific archetypes and other
complexities that I wasn't ready for yet.

Day two…
I worked with a nice person on the Maven IRC channel who walked me through
getting Maven to compile Groovy in the most familiar way possible. We used
the ant-run plugin for this. I put the following in my pom.xml:

<build>
<plugins>
<plugin>
<artifactId>maven-antrun-plugin</artifactId>
<executions>
<execution>
<id>compile</id>
<phase>compile</phase>
<configuration>
<tasks>
<taskdef name="groovyc"
classname="org.codehaus.groovy.ant.Groovyc">
<classpath refid="maven.compile.classpath"/>
</taskdef>
<groovyc destdir="${project.build.testOutputDirectory}"
srcdir="${basedir}/src/main/java/" listfiles="true">
<classpath refid="maven.compile.classpath"/>
</groovyc>
</tasks>
</configuration>
<goals>
<goal>run</goal>
</goals>
</execution>
<execution>
<id>test-compile</id>
<phase>test-compile</phase>
<configuration>
<tasks>
<taskdef name="groovyc"
classname="org.codehaus.groovy.ant.Groovyc">
<classpath refid="maven.compile.classpath"/>
</taskdef>
<groovyc destdir="${project.build.testOutputDirectory}"
srcdir="${basedir}/src/test/java/" listfiles="true">
<classpath refid="maven.test.classpath"/>
</groovyc>
</tasks>
</configuration>
<goals>
<goal>run</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>

That bound the groovy compiler to both the compile and test-compile phases so
now I can run eithermvn compile

or

mvn test-compile to generate bytecode from my groovy sources. I started to
think, "this is better than I thought!" Then I ran:

mvn test

…and got my first failure. Big problem! All I see is the name of the test
that failed and no error info! Now I figure I can dig into Maven and get it
to spit out more info or I can run the test in question interactively under
my IDE and see better what's wrong. (Incidentally, I know what the error is
but since this is an exercise in learning as well as TDD I won't short
circuit the process.) Herein lies my current struggle. It a whole other day
has come and gone and I still don't have an answer. On the Groovy site it
explains how I can use the groovy.util.AllTest suite but when I tried that I
got an error saying that an Ant class couldn't be found. I don't want to pull
Ant in just to run a test in a project that should be M2 based. I may end up
eating those words but for now I'm still trying to find my way. I gotta sign
off now since I have some other work to do. I'll write more about my
experiences later.

[End email snip]

6 thoughts on “Cutting Edge Development

  1. Hi !

    When you run Maven tests, the test reports are published to under “target/surefire-reports” folder as both XML and text files. You can find the test failure details there.

    Happy blogging!!

    Cheers,

  2. Hi Rahul,

    Thank you for your comment. I've figured out a little more about how the surefire plugin works. In the process I learned that you can set a flag on the command line"-Dsurefire.useFile=false" and that causes failure details to show on screen. I was once told that Maven shouldn't be used for inspecting the indiviual failures of certain tests and I see why, however that little trick helps when your project is smaller.

    Thanx for the feedback!

  3. Hi,

    I too had my fun time learning and using Maven and then migrating to Maven 2. One resource that I got aware of very late (this week actually) but not too late is this great ebook: ‘Better Builds with Maven’ ( http://www.mergere.com/m2book_download.jsp ).

    This book really covers the basics and beyond and it’s free (email address required).

    Have fun devloping and blogging!

    Markus

  4. Thank you Markus,

    I too have a copy of that book now. I’m definitely brushing up on my Maven2 knowledge.

    I’ll holla at’cha,
    Cliff

  5. Hi,
    you wrote that “Groovy syntax is a superset of Java syntax”. That would be a
    really cool thing, but it isn’t so. For instance Groovy doesn’t understand
    (anonymous) inner classes.
    Regarding Eclipse (or the other dinosaurs) I prefer the fastest insect
    environment that I can adapt fast to my needs at the same time I program: vim
    Maven2 is however I look worth, I think.
    Thanks for the posting.
    Iván.

  6. Iván,

    Thanx for your comment. That is true that Groovy is not exactly a superset of Java syntax, though I (and probably others) like to think of it as such because it comes pretty close. Regarding vim, I’ve heard many people rave about it and I think I have a copy installed on my Kubuntu distro so maybe I’ll give it a look. I’ve used vi in the past and while I do appreciate its simplicity I find trouble working with editors that require you to remember what keys accomplish what task. Maybe vim will be easier in that regard.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s