Integrating Groovy with Maven 2

It took me all of about 5 minutes to set up an existing project to use Groovy. The first thing (I suppose) to worry about is the directory structure. I say to do this first simply because it's not completely obvious. Basically, you just put a "groovy" directory at the same level as your "java" directory under src/main and src/test. Like this:

This tells the Maven 2 plugin where to find your .groovy files.

Next, you need to change your pom.xml file to do 2 things: 1) compile the .groovy classes first, and 2) add the groovy jar dependency. Both of these are super simple.

First, modify the "plugins" section of your pom.xml file to include the Groovy plugin. Make sure you put the Groovy plugin before the Java compiler plugin. This will allow your Java classes to transparently use the Groovy classes.

Next you need to add the following to your dependency section (note, you may want to check on the version number. If a more recent version is available, use that instead.)

And that's it! Really! (I highly recommend getting IDEA 7.0. It offers great Groovy support, and a very cool bi-directional compiler that make it so your Groovy and Java classes can have about the same level of IDE support.)

Groovy Web Services

You won't believe how incredibly easy web services are in Groovy. Web services are suddenly easy to use, and not a major pain in the caboose. If you really want to appreciate what Groovy can to for you, check out how web services in Java are usually handled, using Axis (there's a good article on this at Java Boutique). Traditionally, you need to deal with wsdl files, and stub classes, and all kind of icky, confusing nastiness. Not with Groovy.

Check Groovy's sites for a good overview on Groovy web services. Here's the quick and dirty. You want to create a web service in Groovy? How about something like this:

Can you believe that's a web service? Yep, a fully functional web service with an associated WSDL and everything. How does a client interact with that? Oh, you are not going to believe this!

Where's the magic? Your looking at it. We're able to dynamically create the proxy class, and reference the methods exposed in the web service as if they were local methods. Suddenly web services are cool again!

There is a proposal in place for a RESTful web service API, but currently the push for this is more in the context of Grails. However, implementing a RESTful web service would likely be quite easy when you can make use of the object-based switch statements, GStrings, and XML parsers. Not quite as magical as SOAP-based web services, but easy nonetheless.

Groovy XML Parsing

In a rather dated article (2004), Jack Herrington does a good job of explaining Getting Groovy with Java. He outlines how XML is usually handled in Java, and how it evolved to being handled in Groovy. It's certainly worth a read, but let's focus on Groovy today. What kind of options do we have for parsing XML files in Groovy?

Just for kicks, let's stick with the same XML that was generated in my last post on Groovy:

How would we go about parsing this in Groovy? Well, one way would be to use the Groovy XmlParser class. That code would look something like this:

You'll notice that, through the magic of the dynamic language, we can treat the XML tree as an object.

What about attributes? They are accessed with the '@' identifier. For example, if your emailAddress xml had a "location" attribute, we would access it using:

or

Groovy's XmlSlurper is another way to parse XML (and fun to say), but I don't completely understand it yet. I encourage you to search for it. Here's something to get you started.

Hudson's Groovy Console Integration

Hudson is a great Continuous Integration system that's really getting some attention lately. One of the nice features it has is an integrated Groovy console where you can run arbitrary Groovy script. Great for figuring out the state of the build. Here's a screen shot of the console screen.

In Conclusion...

I'm sure there are plenty of other examples of what makes Groovy so groovy, so please, if you have any other ideas leave a comment. I'll be happy to look into your suggestions and expand on them.

Have fun!

As I dig deeper, I find that features of the language fall in to four basic categories:

• Wow! That's really groovy!
• Wow! That's really useful!
• Hmmm...that's good to know.
• Nice...but will I use it?

I will focus on the really useful, much of which is also very groovy, but as my boss might say, "groovy don't pay the rent." (He's kind of weird like that.)

Top 10 Grooviest Groovy Features

10 - Brevity (Less is More!)

brev∑i∑ty (br?v'?-t?)
n.

1. The quality or state of being brief in duration.
2. Concise expression; terseness.

Yeah. Definitions are cool! And that pretty well sums up what Groovy gives you in terms of coding. By eliminating some of the scaffolding we normally put in our Java classes, Groovy can cut down that amount of code we have to write substantially. I'm not sure that this is typical, but I recently converted a fairly complex Java class to Groovy. The Java class had 1,800 lines of code. The Groovy equivalent was down to only 1,100 lines of code. I'm not real good with statistics, but that seems to be about a 40% reduction.

This is more of a "Wow! That's groovy!" than useful, but it certainly is nice to have. For me typing less per method means more functionality in the same amount of time. And this is with only about 1 week worth of experience. I look forward to what I can do when I learn the ins and outs of the language.

9 - Ranges

OK, fess up. How many times have you written code that looked a little something like this?

or tried to figure out if a number is between two other number by doing something like this:

Well, Groovy makes this easier, and it's really pretty intuitive. The range format is

[lowerBound..upperBound], [upperBound..lowerBound]or [lowerBound..<upperBound]

So can you guess what this does?

Yep, it prints the numbers 1 through 10. Easy, right? Ok, how do you like this?

That simple little bit of code could be used to see if a letter is between 'a' and 'z'. (Note: you probably wouldn't use ranges to figure out if a character was a letter, that's just here for illustration purposes. More likely you'd use the "~", "=~", or "==~" operators, which let's you evaluate regular expressions. Make sure you check out Groovy's Regular Expression support page.)

Now falling right in to the groovy and useful category is how you can use these ranges in switch statements. Let's say, for example, that you have an insurance company that has different rates depending on the age range of the policy holder. That code might look a little something like this:

Ranges aren't limited to predefined goodies like numbers and letters. You could also create an array, or dates, or any other comparable objects, and use those in your range statements.

8 - GroovyBeans

Much more "groovy" than useful, but certainly does cut down substantially on the extra scaffold code you need to write, GroovyBeans are just like JavaBeans, but a lot smarter.

In Java, you might create a simple Person class with a first name, a last name, and an email address. You create the private variables for each of these, and then getters and setters for each. You do the same thing time after time...or usually let your IDE do it for you. Your code for this Person object would probably look almost exactly like this:

Ho hum...how monotonous. How boring! If the IDE can generate those getters and setters for us, why can't Java? Well, because Java's not Groovy (though Groovy is Java). The Groovy equivalent of the above class skips all of that getter/setter silliness and you are left with this:

I know, you're saying, "but I need my getters and setters!" Don't worry sport, they're still there, at least as far as your code is concerned. How would Java call each of the methods in the Java class? Maybe...

And how would Java call each of the methods in the Groovy class? Would you guess...

Exactly the same. How would Groovy access each of these? Either using the property name or the getter/setter.

Notice the last line. This introduces something called GStrings (I'm not making this up). It's a way to include the variable values right within the screen. This same methodology is used in Maven, Ant, JSF, and other technologies, so it's nothing new. Just new to your Java code.

How do you set the values? Pretty much like you'd think:

7 - Expando

The Expando class is fashioned off the real-life file folders that expand to fit whatever you put inside them. These fit more into the "groovy" than "useful" category, at least on the surface, but this capability opens the door for some huge dynamic possibilities. Within your code, you can create methods as needed. Here's a trivial example that I borrowed from an excellent book, "Groovy in Action" (buy it now!)

This example shows the creation of a "boxer" Expando, and then shows that the "takeThis" method didn't exist. The "takeThis" method is then created and accessed, as is a fightBack method. This shows one use for Closures, which I'll get to later. While the use for Expando classes may not seem immediately evident, the power of the Expando enables some of Groovy's grooviest features.

6 - Grep

To most geeks, grep is a very useful UNIX command. Groovy brings this kind of power to Java. Here's another example from "Groovy in Action":

Grep here is used to find all of the 4-letter words in the array. A full array of options, and regular expressions, are available to the grep command.

5 - Spring Integration

Spring is a very cool technology, which allows you to dynamically include classes in your classes at runtime. On the downside, Spring configuration is a pain in the butt. From the SpringFrameworks web site:

Using Groovy's builder classes, we are able to use Spring within Groovy without a single bit of XML configuration. (I would put an example below, but I can't find one )

UPDATE:† Ok, my Spring portion was lame.† So, special thanks to Paul King for pointing me to this link.† Told you this Spring stuff was Groovy!† http://groovy.codehaus.org/Using+Spring+Factories+with+Groovy†

Speaking of builders...

4 - Builders

In Groovy, the Builder classes provide an easy way to narrow down repetitive tasks and build non-Groovy items, such as XML and HTML documents, Swing GUIs, and pretty much anything else you can think of that follows a pattern. Let's take a really simple XML example:

In Java in order to create such a document, you'd have to create DOM object, create an element for each person in the tree, and child elements for each attribute, all in some really ugly, hard to read code that I refuse to put here (that exercise is left to the reader...I've been there, and it sucks). In Groovy, to build this XML object, you would do something like this:

Can you tell what that does? Easy right?

I put Swing behind me years ago, 'cause it's such a nightmare, but here's a blog post that gives a quick look at building a simple Swing application in both standard Swing, and using Groovy's SwingBuilder class.

http://codetojoy.blogspot.com/2007/08/groovy-swingbuilder-and-secret-methods.html

Builders are not limited to what the guys at Groovy imagined. Through the magic of the Expando classes mentioned earlier, Groovy allows you to create your own builders with ease. More on these builders can be found on the Groovy web site.

3 - Unit Testing, Mocks, and Stubs

Unit testing in Groovy is so useful, and, well, groovy, that the "Groovy in Action" book mentioned earlier has an entire chapter devoted to it. Because I feel this is important, I am going to include a boatload of links, and an example or two for your convenience. Groovy makes unit tests, mock classes, and stubs much easier than standard JUnit tests. Almost easy enough to encourage developers to actually write tests. Here are some important reads:

• Groovy - Unit Testing
• Practically Groovy: Unit Test Your Java Code Faster with Groovy (IBM)
• Groovy Unit Testing
• Groovy Mocks
• Groovy Testing Guide

The gist of it is that you can create you unit tests, to test your Java classes, in Groovy. Or, if you are testing your Groovy code, you can create in-line stubs and mocks to test your code. Jeff Brown gave some good examples at his NFJS presentation.

This class simply writes a message to a file in reverse. How would you unit test this in Java. Well, in reality, you really couldn't, not with a unit test. Maybe an integration test, because in Java you'd end up testing the file system (using the file.exists and file.write methods), not just your code. That's an integration test, my friend. Unless you can somehow throw a mock or stub at the problem. But how, oh how when the file object is inside the method? Groovy makes mocks and stubs easy.

Let's take a look at using the StubFor class to stub out the file object.

Here we are telling the JVM to use our stubFile in place of the File object within our stubFile.use block. How easy is that?

Mocks work the same way, but it's more of a white box test, where you can specify which methods are to be called while testing.

2 - Closures (and Delegates)

On the surface, closures seem a whole lot like Java's anonymous inner classes, though they are easier to use, and much more flexible. They have been shown in previous example without any explanation. Closures are basically blocks of code that take parameters. Sound a little bit like a function? Yep. A function that you can pass around, and which continues to have access to the local variables of where it was created, even when passed around. Like anonymous inner classes without the need to worry about that ugly "final" keyword.

This simple concept can be used in unit tests, pretty much anywhere else you can think of that it might be useful to pass a function around.

Then there's the idea "delegates". Pretty cool stuff. You can define a closure, and then delegate all calls within that closure to any given class. For example, I might have a closure that looks like this:

This closure could work with many different classes. Anything that has an "append" method. the StringBuffer comes to mind. So how do I get the appender to use the StringBuffer? Something like this:

Here the closure will call the append method on the buffer class. The possibilities here are endless!

1 - ExpandoMetaClass

The ExpandoMetaClass allows you to do the impossible. Add methods to existing classes. The String class, by design, can not be extended. So how in the world would you go about adding a "swapCase" method to the String class? (An incredibly useful method that would return a reverse-cased representation of a given String.) Easy. Use the ExpandoMetaClass from Groovy. (From the Groovy Web Site)

This actually changes the byte code for the String class, making the swapCase method available for the entire life of the JVM. Imagine being able to dynamically change any class you want to, on the fly.

This same methodology can be used to override methods in otherwise un-overridable files. Let's say you find a bug in some open source software you are using. You can either wait for the bug to be fix, fix it yourself and submit it back to the project, or override the method in your own code to make use of a quick fix.

I'm sure I'll look back at this post a few short months from now and have different options, and a different order, but as of right now, this stuff just rocks.

The sessions I attended were heavy into dynamic programming languages, and agile software development. The dynamic programming languages that we got deepest into were Groovy and Ruby. Both of these languages make the job of the developer exponentially easier, and are ideal for rapid application development. This in and of itself should be enough to convince developers to use it, but it gets better. Through the magic of dynamic programming, things become possible that were not possible before, which opens up a whole new world of possibilities that blow my mind.

The agile discussions focused on what's right, and wrong, with various agile processes. There were a lot of really great tips, and it was as good to hear about what we are doing wrong as it was to hear about what we are doing wrong.

So the fascination part should be pretty clear. By the end of the weekend I had soaked in so much great information, and had learned so much, that I had that partially numb, partially tingly feeling that is fairly unique to such an experience. There is no question that I will be attending as many NFJS conferences as I can manage. At least one a year. The knowledge exchange, and networking, were absolutely invaluable.

What was frustrating for me is coming to the realization that I have lost (or more likely misplaced) my edge. I find it exceedingly important to select the technologies that are best to solve a given problem. Choosing the right technology can make the difference between a good solution, and a great solution, or even between a failed project and a raging success. Despite my strong feelings on this, I find myself settling on technologies that I am comfortable with. This is clearly not the way I want to develop my career, and not fair to those that count on my technical expertise to solve their problems.

So this stagnant period in my technological development is frustrating. It is certainly possible that I am being too hard on myself, and that always sticking with Java has been the right decision, but I seriously doubt it. The project I am currently working on, for example, could clearly benefit from the dynamic nature of Groovy, and would also likely have been well served by Grails, and had I been paying more attention, I could have offered that guidance early in the project's lifecycle. We're almost to the point where it's too late to bring something like this in, so convincing those I work with that, "I was wrong before...but I'm right now!" is going to be nearly impossible.

On a positive note, like they say, the first step in dealing with a problem is recognizing that there is a problem, so keep checking back here to follow me in my quest to find my place in this techno-world again.