The long way round…

I used Groovy a couple of years back and loved it.  But then did nothing with it.  Then Graeme Rocher, author of The Definitive Guide to Grails, came over to our offices to deliver a course on test-driven development.  After that I got interested in Grails - a web framework that brings the coding by conventions paradigm to Groovy to simplify application development. 

So I refreshed my memory with Groovy by reading the following:

• All the documentation at the groovy web site

Now, ready to flex my Groovy muscles I downloaded and installed:

•  The Eclipse groovy plugin. 

Then with that installed I ran through numerous examples.  But before you do anything, I think you simply have to read about Closures.  To my mind, one of the most powerful and well implemented features within Groovy. 

So I’m up and away with Groovy, then next logical step is to see how easy it is to integrate with some legacy Java applications that I have wandering around.  Also, just how easy is it to debug in and is the Eclipse plugin up to it. 

Okay, okay, I admit it, I’ve been slack. No one is too busy to blog, but this one I’m going to keep brief.

One of the big issues I have when building software artefacts is getting the release number into the product as part of the build. The current product we are working on is a Java web application that uses Maven 2 as its build system. Now, thanks to colleague of mine, Master Merlyn, who also beat me up over my lack of blogging, we have a solution. Enter version 2.0.1 of the maven-war-plugin. What this little beauty does is enable you to apply filters to resources within your webapp as part of the build that give you access to elements within your pom.xml file. For example:

<build>
…
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>2.0.1</version>
<configuration>
<webResources>
<resource>
<directory>src/main/webapp</directory>
<filtering>true</filtering>
<includes>
<include>**/*.jsp</include>
</includes>
</resource>
</webResources>
</configuration>
</plugin>
…
</build>

Now if I want to add the version number (or any other pom element) to any of my jsp files I do the following:

<p> My Application Version: ${pom.version}</p>

Sweet!

But there are a couple of things to note:

1. Use version 2.0.1 of the maven war plugin.
2. Narrow the scope of the files you filter with <includes/>
3. Binary files - exclude them!

That’s it. Enjoy.

In a previous post I talked about the pain I’m in trying to give up Intellij and move over to Eclipse. I was just about there this week when this happens…damn, damn and double damn!

Just over two and half years ago I embarked upon a large-ish Java-based ecommerce project and was pretty much pushed into Struts as the presentation layer. Struts was well known. Struts was not beta code. People on the team were skilled in Struts. The Struts community was large. So, Struts it was. Also, we needed a way to break up the web pages into manageable smaller chunks, so Tiles was the natural choice. Struts and Tiles. Tiles and Struts. Struts, Struts, Struts, Struts, Strutssss…….enough already, let’s do Struts.

I never liked Struts! I can’t put my finger on it, but I was always working around it, never with it. Another sure indicator for me was that I never really wanted to learn it. Sure, I read stuff, but only when I had a problem to fix. Typically with things you like, you do the tutorials and you enjoy them. You then read around edges, check out the news groups and blogs, gauge the community feeling, and generally dig deeper because want to learn more. So I can pretty much say for certain that Struts didn’t do it for me. Struts and I were never friends!
Now, half way through this ecommerce project we get a new web dev who says, “Why are we using this crap (tiles)? Have you not heard of sitemesh, tapestry or webwork?”. Too deeply entrenched in Struts (and boy does it lead you down a yellow brick road to hell) we couldn’t act on the web dev’s advice. (He is still miffed about doing Struts to this day!)

I have since left that project and started another web-based project. I decided to put my old web dev’s recommendations to the test. I went with WebWork and SiteMesh. Enlightenment. I cannot tell you what a joy it is to work with these two web-based technologies from opensymphony. It as though they have not only kept things simple but have provided a tool box thats enable those people that need to do complicated things. And right there IS big difference for me between WebWork and Struts. WebWork is a framework that acts as a tool box that you use to build web sites. You can start small and get bigger. Use this tool, that tool and/or somebody elses tool. The integration with other techologies (Hibernate, Spring, Freemarket, Velocity, Sitemesh, yada, yada, yada) is smooth. Struts, in comparison, is large and clunky. Sorry, but that’s just the way it is. It’s as though from day one you step into ring with Struts and fight until someone, typically Struts, is the winner.

I am not going to go into the details of WebWork and SiteMesh, except to say if you are a Struts and Tiles web developer, you must, absolutely must, no questions asked, try them out. Take off your Struts boxing gloves and try something new. It took me 2 days to grasp the basics of WebWork. In that time I implemented a web site that provided most of the horizontal services that I need in place such as securing uris, logging, timing requests and handling dumb ass users that double-click hyperlinks (why, o why do users do this?) and any unnecessary use of the back button. I’m still impressed.

However, things are changing. Damn, just when you find what you need…stuff happens!

Struts and WebWork are merging. It’s not surprising given WebWork is the superior implementation and Struts has the larger community. The new product is called Struts 2.0. I sincerely hope that the name is more politics and that the product is more like a WebWork 3.0…