Raible Designs

My Incredible Trip to Ireland

If you ever get a chance to travel to Ireland, take it! I don't know when I heard these words, or how they came into my head, but I remembered them clearly when I was first introduced to Barry Alistair by Jeff Genender. Soon after, I was able to negotiate my way into being a speaker at The 2010 Irish Software Show.

The show was last week and I had a blast traveling to Dublin to speak and explore. My sister came me on this trip, but missed a connection in Seattle and had to join me a day late. I left Denver at noon on Monday and arrived at Dublin Airport at 7 am. I was on the same flight as Josh Long and thoroughly enjoyed my iPad as a travel companion. When I got off the plane, my battery life was at 60% and I'd been watching movies and listening to music for 6 hours.

I took a cab through the misty, cool morning to my hotel. I grabbed a coffee, cleaned up, and walked a few blocks to Trinity College for the conference. I made it in time for the opening keynote by Chris Horn. It was an interesting talk, focusing on what needed to happen to make Ireland the Innovation Hub of Europe. After that, I attended Tim Berglund's session on Complexity Theory and Software Development. After lunch and a few more talks, I teamed up with Andres Almiray and Josh Long for a pint at the hotel bar.

That evening, we attended Jeff Genender's talk on Getting into Open Source. The free drinks loosened everyone up and Jeff did a great job with a humorous presentation on how to get Committer Status. After Jeff's talk, about 10 of us headed to a Moroccan restaurant for a late dinner. I was in bed around midnight.

Wednesday morning, my sister arrived in my hotel room at 8 and promptly fell into bed. I set my alarm to sleep an hour and closed the Vegas-style, no-light-allowed curtains. We awoke much later (12:30) than we'd planned (9:00). We quickly got up and headed for some sight-seeing in Dublin. First off, we hit Dublinia and Christ Church Cathedral. Both sites were spectacular and we both learned a lot about the history of Dublin. From there, we skipped across the bridge to The Old Jameson Distillery for a tour and a bit of whiskey.

The picture below was taken on the Ha'penny Bridge as we were heading back from Jameson. The expression of the girl on the left is priceless.

A couple hours later and I was delivering my talk on The Future of Web Frameworks. The crowd was lively; the Guinness I drank while talking was lovely. My session was followed by a Web Framework Experts Panel with Peter Ledbrook (Grails), Jamie van Dyke (Rails), Shay Friedman (ASP.NET MVC), Julian Fitzell (Seaside) and myself (Java Frameworks). The debate was good and there was much discussion about the right apps for each framework and how important statelessness is for scalable applications. After 3 hours of talking, my sister and I headed back to the hotel. I was particularly happy about the evening since it was the first time a family member of mine had seen me speak.

Correction from my Dad: This wasn't the first time a family member saw me speak. He attended my talk at ApacheCon EU 2007.

A block from the hotel, we spotted a nice looking pub (Doyles) and stopped in for a pint. As we bellied up to the end of the bar, we recognized Jamie (from the panel) and got introduced to his friend Rob. We quickly got lost in conversation, stories and laughter and were surprised when we discovered it was 2:30am. Since I had a talk first thing in the morning, we ducked out shortly after.

Thursday started with my talk Comparing Kick-Ass Web Frameworks. Then my sister and I did some more site-seeing, starting at the Guinness Storehouse. We met Josh and John Willis as they were leaving and they advised we go straight to The Gravity Bar at the top. We took there advise and were getting great views of Dublin and savoring sweet pints of Guinness moments later. The tour facility was freakin' awesome and I loved how it was shaped like a pint glass.

We grabbed some gear from the gift shopped and landed (by accident) at The Brazen Head (Ireland's Oldest Pub, Est. 1198) for a pint of cider and Guinness. Since my sister used to be in the cider business, she was particularly happy there was so much on tap in Ireland.

From the pub, we headed to John Willis's session on The Cambrian Cloud Explosion. Following John's session, we headed to the Speaker's Dinner for a very fun evening with the hosts and speakers of the conference.

On Friday, we woke up in the early afternoon and quickly decided the Book of Kells was our best chance of getting some site seeing in. After visiting the Book of Kells, my favorite quote of the conference happened in the courtyard.

Josh looked at Jamie (with his bad hangover) and exclaimed, "My God Man. Your skin is so white it's hurting my eyes!". You probably had to be there (or know Josh) to enjoy the humor, but I wanted to capture the memory in this post so I could laugh whenever I read this in the future. After that, Jamie, Josh, Kalin and I enjoyed a Starbuck's patio talking about living in the South of France for a couple hours. Then we walked 2 blocks to the Porterhouse Brewing Co. to watch the World Cup and enjoy more interesting conversations.

Jamie left the conference that evening and we joined a whole slew of other speakers for dinner at an excellent Lebanese restaurant near Temple Bar. Good times where had afterwards at a nearby Silent Disco.

Saturday, we woke up early to catch a tour bus out to Glendalough with Josh and John. The bus ride was not pleasant, but the destination was spectacular. We hung out there for several hours, exploring the buildings, walking to the lake and humoring each other.

Our last night in Dublin was an early, relaxing one. As you can tell, I really enjoyed this trip, particularly hanging out with my sister and all the cool people we met. I can easily say that this trip registers as one of my favorite conference experiences to date.

To see all the pictures I took on this trip, check out my Irish Software Show 2010 set on Flickr.

My Presentations from The Irish Software Show 2010

This week I've been enjoying Dublin, Ireland thanks to the 2nd Annual Irish Software Show. On Wednesday night, I spoke about The Future of Web Frameworks and participated in a panel with Grails, Rails, ASP.NET MVC and Seaside developers. It was a fun night with lots of lively discussion. Below is my presentation from this event.

This morning, I delivered my Comparing Kick-Ass Web Frameworks talk. This presentation contains updated statistics for various metrics comparing Rails vs. Grails and Flex vs. GWT.

Thanks to all who attended my talks this week!

P.S. I believe audio was recorded on Wednesday night, but I'm unsure how it turned out. I'm pretty sure no recordings were done on this morning's session.

A Nice Riding Weekend before heading to the Emerald Isle

I'm writing this post while waiting to board a flight to the Irish Software Show in Dublin, Ireland. Before I go, I thought I'd let y'all know about the killer weekend I had tooling around on my bike.

Saturday was Big Head Todd and the Monsters at Red Rocks, so I had the pleasure of joining Bruce and The Professor for our annual Ride to Red Rocks. We were slow getting out there (as usual), but had a great time at the show. 17th row seats and plenty of excellent music. The ride home was dark and fast; arriving at my house at 1:30. After late night Jerusalems, I crawled in bed at 2:30.

Six hours later, I hopped out of bed, jumped in my car and drove down to Castle Rock for Elephant Rock. I did the 25-mile off-road ride on my mountain bike. Unfortunately, there was no singletrack, and I'm pretty sure I was the last one to start the race. The ride itself was nice and windy with plenty of sun. When I reached the highway on the backside of Castlewood Canyon, I caught a stellar tailwind and had a blast cruising to the finish line.

If you'd like to see more pictures from my weekend biking adventures, checkout my Big Head Todd and Elephant Rock set on Flickr.

If you're going to be at the Irish Software Show this week, be sure to stop by and say hi. I'll be speaking about The Future of Web Frameworks on Wednesday at 7:30pm and Comparing Kick-Ass Web Frameworks early on Thursday morning.

Mountain Biking in Moab

Ever since I first learned to ride a bike when I was 5 years old, I've been a huge fan. In grade school, I got into freestyle, BMX and even did a bit of racing. After college, I re-invested myself in biking and started riding to work. Soon after, I got into mountain biking and have loved it ever since. When it's summertime in Colorado, I prefer to be on a bike, riding singletracks with the sweet smell of the Rockies in the air.

Moab is the Mecca of mountain biking. It was with much anticipation that I began a journey there last weekend with my good friend Matt Good. Matt was going for the music, while I was primarily interested in the singletrack. We left Denver on Wednesday evening and stayed the night in Grand Junction. On Thursday, we stopped at a bike shop in Fruita, got some recommendations and headed for Utah.

Our first trail was Klondike Bluffs to Baby Steps. The trail began with dirt and quickly shifted to riding on bumpy slickrock. At the top, we hiked into Arches National Park and enjoyed some spectacular views. From the top of Klondike Bluffs, we hit Baby Steps and cruised along a red singletrack for most of the afternoon.

Our first ride in Moab took us almost 4 hours and we only covered 15 miles. With smiles on our faces, we enjoyed some cold beers and hopped in the car to head to the first night of Desert Rocks. The 4-day concert was held at Area BFE about 10 miles south of Moab. It was a very cool venue with a couple thousand music fans camping along the cliffs. It was definitely easy-living as far as camping goes. Bands played until dawn each night and you could hear it no matter where you slept.

We pitched our tents as darkness was closing in and walked down to the main stage to enjoy some late night entertainment.

The next day, we woke up, enjoyed Matt's famous breakfast burritos and headed into Moab to catch a shuttle to Porcupine Rim Trail. It took an hour to get to the Hazard County Trailhead, but soon after we were zooming down the mountain. The UPS and LPS singletracks near the beginning of the trail were some of the most fun and scenic trails I've ever ridden.

Once we hit Porcupine Rim Trail, I put the pedal to the metal and didn't stop to wait for Matt for a couple hours. Finally, I stopped to make sure he was OK. 30 minutes later, I got a text message from him saying he had a flat, his spare was bad, and he was walking out. Luckily, I had an extra tube and rode back to help him out. I was pretty impressed by iPhone could send/receive text messages out in the middle of nowhere. The Porcupine Rim ride took us 4.5 hours and we tracked 26.75 miles. The several points in the trail with "death on the right" were truly epic.

After another night of great music under the stars, I woke up Saturday and headed for the most famous trail in Moab: Slickrock. Matt declined to join me as he was sore from the previous two days. Up to this point, the rides had been pretty easy. Granted, they were long and we were both super-tired after finishing, but I rarely dropped down into my lower chain ring (in front). I was riding my full-suspension with disc brakes while Matt was riding his Homegrown Hardtail.

Slickrock was even cooler (and harder) than I thought it would be. There were several "hills" that were super-steep and really hard to pedal up. It was possible to pedal up them, but you had to really crank. I found that standing up helped a lot. The scary part of riding these hills was if you didn't make it, there's a good chance you'd crash all the way back to the bottom. I'm proud to say I made it up all but 4 hills and got away with only a minor injury.

The remainder of Saturday was spent listening to good music and enjoying the vibe of Desert Rocks. By this time, most people had arrived and smiling faces were everywhere. Sunday, we took the day off from riding, enjoyed more music, took an afternoon nap and watched another beautiful sunset.

Monday, we packed up and rode Sovereign Singletrack just before noon. We did the relatively easy Garden Mesa 10-mile loop. When we turned off the road onto the singletrack, I heard a crash behind me and looked back to see Matt in the midst of an over-the-handlebars wipeout. Me: "How did that happen?" Matt: "I don't know, but I think I tore my fingernail off."

2 and 1/2 hours later, we were back at the car, packing up to leave Moab. I've never had so much fun riding my bike. The camping and concert was exceptional too. If you ever get a chance to visit Moab for riding or Desert Rocks, I highly recommend it.

All my pictures from this weekend can be found in my Moab and Desert Rocks set on Flickr. In addition, I tracked all our rides using iWander and uploaded them to EveryTrail. You can see the precise routes, times, etc. by clicking on the links below.

• Klondike Bluffs to Baby Steps
• Porcupine Rim
• Slickrock
• Sovereign Singletrack

Abbie and Jack's Field Days

Last week, I had the pleasure of attending my kids' field days. For those who aren't familiar with field days, it's basically a sports day for elementary schools. The best part of this year's field days was seeing my kids have so much fun with their classmates. Of course, it didn't hurt that their teachers were also smitten with the thought of the school year coming to a close.

I took a few pictures and shot a bunch of video to remember how much fun they had. I know most readers won't enjoy these as much as I do, but I always like posting fond memories on this blog. Below are a couple videos I compiled and enhanced with appropriate music.

I especially like Jack's friend's dance moves at the end of the video below.

If you have trouble viewing either video here, check them out on my YouTube channel.

Volkswagens On The Green 2010 and The Bus Project

This weekend, I took Abbie and Jack to the 16th Annual Volkswagens on the Green. I was especially inspired to take them because we've been playing a lot of "Slug Bug" lately and I figured the number of opportunities for points would surely overload their senses. Not only was I right, but this was one of the best VW shows I've been to in Colorado. The venue was great, there were lots of cars and everything was easily accessible.

Personally, the highlight of the show for me was stumbling upon my bus in the midst of the parking lot. Motorworks Restorations hauled it up from the Springs to highlight it as one of their project vehicles. The kids loved seeing it and climbed all over it while I had a conversation with Jeremy (owner of Motorworks) about adding a Porsche suspension and brakes to the mix.

My Bus Restoration Project has been on hold for a couple years and I'm happy to report I'll be starting it again in the next few months. I don't know if we'll finish it this year, but there's a really good chance we'll be driving it to a lot of Colorado VW Shows next year.

For more pictures, click on the images below or see my VWs on the Green set on Flickr.

The Trifecta: 3 Resorts in 3 Days

Last Tuesday night, I worked late in hopes of having a Powder Day on Wednesday. I went to bed at 2 a.m., woke up at 6 a.m. and found that there was only 5" of fresh powder at Winter Park. My ski rule is there has to be 9" of powder in order to justify playing hookie. Working these extra hours on Tuesday -- coupled with a late night on Wednesday -- and I hit my 40-hour-max on Thursday. Naturally, I took Friday off and headed for the hills. Below is how I started my Friday morning.

After several high-speed groomed runs, I hit Mary Jane's bumps a few times (completing Outhouse and Trestle w/o stopping) and watched the Whiteout begin around 11.

Around noon, I began searching for a location to watch DU in the NCAA Hockey Playoffs. Unable to find a bar with ESPN U, I skied until 2 and then headed to my friend's mountain home. He had the game recorded, so I got to watch it and endure its unfortunate outcome. DU played really well, but couldn't beat RIT.

On Saturday, the snow report said 6" at Steamboat and 6.5" at Winter Park. Since we hadn't been to Steamboat in a while, my friend (a.k.a. The Professor) and I decided to drive there for the day. It was an excellent decision because there was easily a foot of fresh powder in the chutes and trees. We skied from 9:30 to 4:00; easily my most difficult day of skiing this year.

On Sunday, I woke up and read the ski report: Copper had 3" of new snow. That's when it hit me that I could pull of The Trifecta. I don't know that I've ever done 3 resorts in 3 days before, but I'm happy to report I've done it now. Sunday was a beautiful day of Spring Skiing and Copper did not disappoint. They'd received 7" inches in 48 hours, making Sunday an awesome day for trees and double blacks. There was plenty of powder, great friends and lots of smiles from everyone. You can see from the pictures below what a beautiful Blue Bird Day it was.

With only 3 weeks left in ski season, I'm happy to report I have 22 days in. With any luck, I'll hit 25 days and set a personal record.

The Cloud Computing Continuum with Bob McWhirter

This afternoon, I sat in a Keynote by Bob McWhirter at TSSJS 2010. Bob is the Chief Architect of Cloud Computing at Red Hat. Bob is "The Despot" at Codehaus, helped start Groovy and founded Drools. Below are my notes from his talk.

The cloud is not an either/or question. A scorched Earth strategy is not necessary to be in the cloud. The cloud is a continuum of technologies, many of those that you're already familiar with. You're used to web, messaging and storage. You can add just a little bot of cloud to your application at a time.

So what is the cloud?

It's the next logical step in application delivery.

How did we get to the cloud? First, we jammed a lot of servers into a closet (back in the .com days). That's a lot of stuff to deal with if all you want to do is deliver an internet-based service. Then we did some colo. The problem with colo was that it was still our stuff. Then we leased managed servers. With the cloud, we lease what appears to be servers (or services). This is a path we've all been taking to abstract the annoying bits away from hosting an internet-based service.

The typical diagram of a cloud has IaaS, PaaS and PaaS. IaaS abstracts away hardware. PaaS abstracts away services. SaaS abstracts away software.

Tenants of the cloud:

• The illusion of infinite resources.
• On-demand acquisition and provision.
• Someone else's responsibility.

Magicians provide the illusion of pulling a card out of your ear, but they don't actually do it. Because there are limits of what we can do. With on-demand requisitioning, there's no more purchase orders. There's no more waiting for delivery. No waiting for IT to rack it. Or install it. By having someone else manage your hardware, it's not your problem. There's clear lines of responsibility. This intentionally limits visibility into the implementation. Hopefully it's best-of-breed.

The Cloud is really just a mindset. Virtualization makes it affordable to make mistakes. Repeatedly. Each service is managed as an autonomous entity. Services are designed for scalability.

Architecture 101 give us a presentation layer, a business logic layer and a persistence layer. You can scale it by putting many instances on many servers. However, the truth is that most apps are a big ball of mud. You need to get your application in order, then figure out which parts really needs to scale. Is the web tier really where we have trouble? Painting HTML isn't all that hard.

You don't have to put everything in the cloud. The cloud is not a revolution. We still need containers for web things, messaging things, storage of things and other things. Containers still exist, they're just in the cloud.

From container to cloud
When you have an application and a database, there's not much to abstract away into the cloud. However, as soon as you notice your DB is slow, you'll add caching. Once you hit your machine's memory limit, you discover distributed caching systems. Once you've done this, you'll discover that the network isn't all that slow, especially compared to spinning disks. Then you realize that you don't even need the storage and you can keep everything in cache. From there, you move to a RESTful caching service. Then you call it a NoSQL Service so you can be buzzword-compliant.

As far as caching services, there's many available, but a lot of them are startups. However, the cloud does not have to mean external 3rd-party providers. Remember DBAs? It was their job to view the database as a service and to protect it. There's a good chance that we'll end up with DBAs for services. By turning caching into an independent service, it becomes subject to economies of scale.

The cloud is a mindset. It's an SOA approach that allows groups to specialize and optimize for scale.

So how do you implementing a local cloud? We already have great caching technologies. Bob, with his JBoss hat on, recommends Infinispan and its REST API. To get around network latency, you can still run your cloud on your LAN. You're essentially trading disk traffic for network traffic. You can use many hands (e.g. MapReduce) to make things happen quickly.

Besides caching, there's a number of other services that can be put in the cloud. For example:

• Messaging (REST-MQ
• Scheduling
• Security & Identity (OASIS, etc)
• Computation (query & otherwise)
• Transactions (REST-TX)
• Business Process Management
• Telephony (VOIP, SMS)

Your application becomes a stack of services, instead of a stack of software.

Higher-order business-logic services are also subject to cloudification. Ultimately, going into the cloud is not rocket science. The cloud does not turn everything on its head. We don't have to wait for new companies to develop new technologies. Startups may be the best consumers of the cloud, but might not be the best providers. We'll let the startups assume the risks for now. Until the 3rd party services have been proven, it's probably best to build your own cloud of services.

More than anything, the cloud has caused a return to fundamentals. Once your app is a collection of services, you can easily pick and choose what pieces you want to put in the cloud. This is where we're headed, whether you like it or not. As more apps become global-scape, you're going to run into these issues. By adopting a cloud mindset and architecture, your app can be prepared for scalability issues.

For more communication with Bob and his Cloud Evangelism, checkout StormGrind or follow him on Twitter.

Personally, I really enjoyed Bob's talk. It was by far the best keynote today, mostly because he told a story and did it elegantly with a nice-looking presentation. Not only that, but he provided the audience with a practical view of the cloud and ways that we can start using it in our applications today.

Update: You can find the slides from this session on SlideShare.

GWT OAuth and LinkedIn APIs

When I worked at LinkedIn last year, I received a lot of inquiries from friends and developers about LinkedIn's APIs. After a while, I started sending the following canned response:

For API access to build LinkedIn features into your application, fill out the following form:

   http://www.linkedin.com/static?key=developers_apis

For requests to build an application, go to:

   http://www.linkedin.com/static?key=developers_opensocial

I talked with the API team and they did say they look at every request that's sent via these forms. They don't respond to all of them b/c they know that many people would be angry if they told them "no", so they'd rather not have that headache.

Yesterday, I was pumped to see that they've finally decided to open up their API to Developers.

Starting today, developers worldwide can integrate LinkedIn into their business applications and Web sites. Developer.linkedin.com is now live and open for business.

First of all, congratulations to the API team on finally making this happen! I know it's no small feat. Secondly, it's great to see them using Jive SBS for their API documentation and developer community. My current client uses this to facilitate development and I love how it integrates a wiki, JIRA, FishEye, Crucible and Bamboo into one central jumping off point.

I've always been a fan of LinkedIn, ever since I joined way back in May 2003. However, I've longed for a way to access my data. LinkedIn Widgets are nice, but there's something to be said for the full power of an API. Last night, I sat down for a couple hours and enhanced my Implementing OAuth with GWT example to support LinkedIn's API.

I'm happy to report my experiment was a success and you can download GWT OAuth 1.2 or view it online. For now, I'm simply authenticating with OAuth and accessing the Profile API.

In the process, I learned a couple things:

• LinkedIn's OAuth implementation returns an oauth_verifier parameter after authenticating, whereas Google and Twitter do not. This parameter needs to be included when calling the Access token path.
• The Profile API example I implemented gets the current user's profile with http://api.linkedin.com/v1/people/~. This returns a "light" version of your profile. To get a more detailed version, you need to use Field Selectors. For example: http://api.linkedin.com/v1/people/~:(id,first-name,last-name,picture-url,headline,summary,positions,educations)
• LinkedIn's API only supports passing OAuth parameters in a header, rather than query parameters. To make this work, I modified my ProxyServlet to convert query parameters to an "Authorization" header at the end of the setProxyRequestHeaders() method.

// For LinkedIn's OAuth API, convert request parameters to an AuthorizationHeader
if (httpServletRequest.getRequestURL().toString().contains("linkedin-api")) {
    String[] parameters = httpServletRequest.getQueryString().split("&");
    StringBuilder sb = new StringBuilder("OAuth realm=\"http://api.linkedin.com/\",");
    for (int i = 0; i < parameters.length; i++) {
        sb.append(parameters[i]);
        if (i < parameters.length - 1) {
            sb.append(",");
        }
    }

    Header authorization = new Header("Authorization", sb.toString());
    httpMethodProxyRequest.setRequestHeader(authorization);
}

You might recall that my previous example had issues authenticating with Google, but worked well with Twitter. LinkedIn's authentication seems to work flawlessly. This leads me to believe that Twitter and LinkedIn have a much more mature OAuth implementation than Google.

Related OAuth News: Apache Roller 5 will be shipping with OAuth support. See Dave Johnson's What's New in Roller 5 presentation for more information.

Update December 6, 2009: I modified the gwt-oauth project to use GWT 1.7.1 and changed to the Maven GWT Plugin from Codehaus. Download GWT OAuth 1.3 or view it online.

Packaging a SOFEA Application for Distribution

The project I'm working on is a bit different from those I'm used to. I'm used to working on web applications that are hosted on servers and customers access with their browser. SaaS if you will. My current client is different. They're a product company that sells applications and distributes them to customers via download and CD. Their customers install these applications on internal servers (supported servers include WebSphere, WebLogic and Tomcat).

The product I'm currently working on is structured as a SOFEA application and therefore consists of two separate modules - a backend and a frontend. Since it's installed in a servlet container, both modules are WARs and can be installed separately.

Building the backend and frontend as separate projects makes a lot of sense for two reasons:

• In development, different teams can work on the frontend and backend projects.
• Having them as separate projects allows them to be versioned separately.

However, having them as two separate projects does make it a bit more difficult for distribution. I'm writing this post to show you how I recently added support for distributing our application as 2 WARs or 1 WAR using the power of Maven, war overlays and the UrlRewriteFilter.

Project Setup
First of all, we have several different Maven modules, but the most important ones are as follows:

• product-services
• product-client
• product-integration-tests

Of course, our modules aren't really named "product", but you get the point. The services project is really just a WAR project with Spring Security configured. It depends on other JAR modules that the services exist in. The client project is a GWT WAR that has a proxy servlet defined in its web.xml that makes it easier to develop. It also contains some UrlRewrite configuration that allows GWT Log's Remote Logging feature to work. The proxy servlet is something we don't want to ship with our product, so we have a separate web.xml for production vs. development. We do the substitution using the maven-war-plugin:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-war-plugin</artifactId>
    <version>2.0.2</version>
    <configuration>
        <!-- Production web.xml -->
        <webXml>src/main/resources/web.xml</webXml>
        <warSourceDirectory>war</warSourceDirectory>
        <!-- Exclude everything but urlrewrite JAR -->
        <warSourceExcludes>
            WEB-INF/lib/aop**,WEB-INF/lib/commons-**,WEB-INF/lib/gin-**,
            WEB-INF/lib/guice-**,WEB-INF/lib/gwt-**,WEB-INF/lib/gxt-**,
            WEB-INF/lib/junit-**
        </warSourceExcludes>
    </configuration>
</plugin>

I could exclude WEB-INF/lib/** and WEB-INF/classes/**, but in my particular project, we still want UrlRewrite in standalone mode, and we have some i18n properties files in WEB-INF/classes that are served up for Selenium tests.

With this configuration, we have a services WAR and a client WAR that can be installed and used by clients. To collapse them into one and make it possible to ship a single war, I turned to our product-integration-tests module. This module contains Selenium tests that test both types of distributions.

Merging 2 WARs into 1
The most important thing in the product-integration-tests module is that it creates a single WAR. First of all, it uses <packaging>war</packaging> to make this possible. The rest is done using the following 3 steps.

1. Its dependencies include the client and servlet WARs (and Selenium RC for testing).

<dependencies>
    <dependency>
        <groupId>com.company.app</groupId>
        <artifactId>product-services</artifactId>
        <version>1.0-SNAPSHOT</version>
        <type>war</type>
    </dependency>
    <dependency>
        <groupId>com.company.app</groupId>
        <artifactId>product-client</artifactId>
        <version>1.0-SNAPSHOT</version>
        <type>war</type>
    </dependency>
    <dependency>
        <groupId>org.seleniumhq.selenium.client-drivers</groupId>
        <artifactId>selenium-java-client-driver</artifactId>
        <version>1.0.1</version>
        <scope>test</scope>
    </dependency>
</dependencies>

2. The WAR created excludes the "integration-tests" part of the name:

<build>
    <finalName>product-${project.version}</finalName>
    ...
</build>

3. WAR overlays are configured so the everything in the client's WEB-INF directory is excluded from the merged WAR.

<plugin>
    <artifactId>maven-war-plugin</artifactId>
    <configuration>
        <!-- http://maven.apache.org/plugins/maven-war-plugin/overlays.html -->
        <overlays>
            <overlay>
                <groupId>com.company.app</groupId>
                <artifactId>product-services</artifactId>
                <excludes>
                    <!-- TODO: Rename to api.html (this is the Enunciate-generated documentation) -->
                    <exclude>index.html</exclude>
                </excludes>
            </overlay>
            <!-- No server needed in product-client -->
            <overlay>
                <groupId>com.company.app</groupId>
                <artifactId>product-client</artifactId>
                <excludes>
                    <exclude>WEB-INF/**</exclude>
                </excludes>
            </overlay>
            <!-- Only include META-INF/context.xml to set the ROOT path -->
            <overlay>
                <excludes>
                    <exclude>WEB-INF/**</exclude>
                </excludes>
            </overlay>
        </overlays>
    </configuration>
</plugin>

That's it! Using this configuration, it's possible to distribute a Maven-based SOFEA project as single or multiple WARs. However, there are some nuances.

One thing you might notice is the reference to META-INF/context.xml in the overlays configuration. This subtly highlights one issue I experienced when merging the WARs. In our GWT client, we're using URLs that point to our services at /product-services/*. This works in development (via a proxy servlet) and when the WARs are installed separately - as long as the services WAR is installed at /product-services. However, when they're merged, a little URL rewriting needs to happen. To do this, I added the UrlRewriteFilter to the product-services module and configured a simple rule.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCENGINE urlrewrite PUBLIC "-//tuckey.org//DTD UrlRewrite 3.0//EN"
        "http://tuckey.org/res/dtds/urlrewrite3.0.dtd">

<urlrewrite use-query-string="true">
    <!-- Used when services are merged into WAR with GWT client -->
    <rule>
        <from>^/product-services/(.*)$</from>
        <to type="forward">/$1</to>
    </rule>
</urlrewrite>

Because the services URLs point to the root (/product-services), the merged WAR has to be installed as the ROOT application. When you're using Cargo with Tomcat and want to deploy to ROOT, you have to have a META-INF/context.xml with a path="" reference (ref: CARGO-516).

<Context path=""/>

It is possible to change the URLs in the client to be relative, but this gets seems to get messy when you're using separate WARs. When using relative URLs, I found I had to do solution using cross-context forwarding to get the results I wanted. Using a redirect instead of a forward worked, but resulted in the client talking to the server twice (once to get redirected, a second time for the actual call). Cross-context forwarding is supported by the UrlRewriteFilter and Tomcat, but I'm not sure WebSphere or WebLogic support it. The best solution is probably to change the URLs dynamically at runtime, possibly using some sort of deferred binding technique.

Testing with Cargo and Selenium
Once I had everything merged, I wanted to configure Cargo and Selenium to allow testing both distribution types. If I installed all 3 wars at the same time, the "product-services" WAR would be used by both the product-client.war and the product.war, so I had to use profiles to allow installing the single merged WAR or both WARs. Below is the profile I used for starting Cargo, deploying the merged WAR, starting Selenium RC and running Selenium tests.

<properties>
    <cargo.container>tomcat6x</cargo.container>
    <cargo.container.url>
        http://archive.apache.org/dist/tomcat/tomcat-6/v6.0.20/bin/apache-tomcat-6.0.20.zip
    </cargo.container.url>
    <cargo.host>localhost</cargo.host>
    <cargo.port>23433</cargo.port>
    <cargo.wait>false</cargo.wait>
    <cargo.version>1.0</cargo.version>

    <!-- *safari and *iexplore are additional options -->
    <selenium.browser>*firefox</selenium.browser>
</properties>
...
<profile>
    <id>itest-bamboo</id>
    <activation>
        <activeByDefault>false</activeByDefault>
    </activation>
    <build>
        <plugins>
            <plugin>
                <groupId>org.codehaus.cargo</groupId>
                <artifactId>cargo-maven2-plugin</artifactId>
                <version>${cargo.version}</version>
                <configuration>
                    <wait>${cargo.wait}</wait>
                    <container>
                        <containerId>${cargo.container}</containerId>
                        <log>${project.build.directory}/${cargo.container}/cargo.log</log>
                        <zipUrlInstaller>
                            <url>${cargo.container.url}</url>
                            <installDir>${installDir}</installDir>
                        </zipUrlInstaller>
                    </container>
                    <configuration>
                        <home>${project.build.directory}/${cargo.container}/container</home>
                        <properties>
                            <cargo.hostname>${cargo.host}</cargo.hostname>
                            <cargo.servlet.port>${cargo.port}</cargo.servlet.port>
                        </properties>
                        <!-- Deploy as ROOT since XHR requests are made to /product-services -->
                        <deployables>
                            <deployable>
                                <properties>
                                    <context>ROOT</context>
                                </properties>
                            </deployable>
                        </deployables>
                    </configuration>
                </configuration>
                <executions>
                    <execution>
                        <id>start-container</id>
                        <phase>pre-integration-test</phase>
                        <goals>
                            <goal>start</goal>
                        </goals>
                    </execution>
                    <execution>
                        <id>stop-container</id>
                        <phase>post-integration-test</phase>
                        <goals>
                            <goal>stop</goal>
                        </goals>
                    </execution>
                </executions>
            </plugin>
            <plugin>
                <groupId>org.codehaus.mojo</groupId>
                <artifactId>selenium-maven-plugin</artifactId>
                <version>1.0</version>
                <executions>
                    <execution>
                        <phase>pre-integration-test</phase>
                        <goals>
                            <goal>start-server</goal>
                        </goals>
                        <configuration>
                            <background>true</background>
                        </configuration>
                    </execution>
                </executions>
            </plugin>
            <plugin>
                <artifactId>maven-surefire-plugin</artifactId>
                <executions>
                    <execution>
                        <phase>integration-test</phase>
                        <goals>
                            <goal>test</goal>
                        </goals>
                        <configuration>
                            <excludes>
                                <exclude>none</exclude>
                            </excludes>
                            <includes>
                                <include>**/*SeleniumTest.java</include>
                            </includes>
                            <systemProperties>
                                <property>
                                    <name>selenium.browser</name>
                                    <value>${selenium.browser}</value>
                                </property>
                                <property>
                                    <name>cargo.port</name>
                                    <value>${cargo.port}</value>
                                </property>
                            </systemProperties>
                        </configuration>
                    </execution>
                </executions>
            </plugin>
        </plugins>
    </build>
</profile>

This profile is run by our Bamboo nightly tests with mvn install -Pitest-bamboo. The 2nd profile I added doesn't install the project's WAR, but instead installs the two separate WARs. Running mvn install -Pitest-bamboo,multiple-wars executes the Selenium tests against the multi-WAR distribution.

<profile>
    <id>multiple-wars</id>
    <activation>
        <activeByDefault>false</activeByDefault>
    </activation>
    <build>
        <plugins>
            <plugin>
                <groupId>org.codehaus.cargo</groupId>
                <artifactId>cargo-maven2-plugin</artifactId>
                <version>${cargo.version}</version>
                <configuration>
                    <configuration>
                        <home>${project.build.directory}/${cargo.container}/container</home>
                        <properties>
                            <cargo.hostname>${cargo.host}</cargo.hostname>
                            <cargo.servlet.port>${cargo.port}</cargo.servlet.port>
                        </properties>
                        <deployables>
                            <deployable>
                                <groupId>com.company.app</groupId>
                                <artifactId>product-client</artifactId>
                                <pingURL>http://${cargo.host}:${cargo.port}/product-client/index.html</pingURL>
                                <type>war</type>
                                <properties>
                                    <context>/product-client</context>
                                </properties>
                            </deployable>
                            <deployable>
                                <groupId>com.company.app</groupId>
                                <artifactId>product-services</artifactId>
                                <pingURL>
                                    http://${cargo.host}:${cargo.port}/project-services/index.jspx
                                </pingURL>
                                <type>war</type>
                                <properties>
                                    <context>/product-services</context>
                                </properties>
                            </deployable>
                        </deployables>
                    </configuration>
                </configuration>
            </plugin>
        </plugins>
    </build>
</profile>

I won't be including any information on authoring Selenium tests because there's already many good references. I encourage you to checkout the following if you're looking for Selenium testing techniques.

• Carlos Sanchez's Selenium Test Environment for AppFuse
• Testing Ext JS & Ext GWT Applications With Selenium
• Testing Nexus with Selenium: A lesson in complex UI testing (Part 1)
• Testing Nexus with Selenium: A lesson in complex UI testing (Part 2)
• Testing Nexus with Selenium: A lesson in complex UI testing (Part 3)

Summary
This article has shown you how I used Maven, war overlays and the UrlRewriteFilter to allow create different distributions of a SOFEA application. I'm still not sure which packaging (1 WAR vs. 2) mechanism is best, but it's nice to know there's options. If you package and distribute SOFEA applications, I'd love to hear about your experience in this area.