Search for [ant] in weblog rd

JHipster Conf 2018: Summer Solstice in Paris

2018-06-28T10:13:27-06:00

Last week, I journeyed to Paris with my son, Jack. It was his first time in Europe and I brought him along for good reason. I’d been invited to the first ever JHipster Conf, and I was eager to attend. We were both pretty excited when we left Denver last Monday.

Our adventure to Paris begins! #jhipsterconf

A post shared by Matt Raible (@vwsforlife) on Jun 18, 2018 at 4:01pm PDT

My Background with JHipster

I’ve been a part of the JHipster community for a few years now. I joined by accident, really. I was trying to market myself as an independent consultant by spouting my knowledge of Spring Boot and Angular with an InfoQ mini-book. Since JHipster leveraged both to jumpstart app development, it seemed like a perfect fit. I’ve been a long-time fan of app jumpstarts, having developed my own called AppFuse in days long gone.

Through the process of writing the mini-book, finding issues, and submitting pull requests, I eventually found myself to be a member of the JHipster development team. Through my relationship with JHipster, and it’s 3.0 release, I found myself intrigued my microservices and how to develop them with Spring Boot, Spring Cloud, all through the generation expertise of JHipster.

I’ve learned a ton by being part of the project and trying to figure out how all of its options work.

When I found myself with a full-time job at Stormpath, I did my best to create a Stormpath module for JHipster. When Okta acquired Stormpath, I added a similar module to my list of things I wanted to write.

When it came time to implement an Okta module, I discovered JHipster’s OAuth support only worked internally, not with an external OAuth provider, also known as an Identity Provider, or IdP. I mentioned to the JHipster team I thought we could do better and add support for external providers instead. They agreed, and I went to work.

In hindsight, it was a great decision and not terribly difficult to implement thanks to Spring Security, Keycloak, and Docker. We had a ton of help from the community along the way, and as of last October, JHipster added support for single sign-on with OIDC (tested with Keycloak and Okta).

JHipster 5.0: Spring Boot 2.0, Angular 6, and React

It’s been a fabulous adventure on the JHipster train and it’s still going strong. We just released version 5.0 with React and Spring Boot 2.0 support, there’s client generators for Ionic and React Native, and we just hosted a kick-ass conference about JHipster in Paris.

JHipster Conf 2018

The conference featured members of the core team, the well-dressed and fit Joe Kutner from Heroku, as well as Java celebrities like Ray Tsang and Josh Long. You can read about the festivities and presentations from JHipster's founder, Julien Dubois.

The conference was a little over 24 hours long, starting with a speaker’s dinner on Wednesday evening. Before attending, Jack and I spent the day strolling around Versailles. Versailles is a special place in my life since I proposed to my double rainbow there after Devoxx Belgium in 2011.

?? Versailles #working #jhipsterconf

A post shared by Matt Raible (@vwsforlife) on Jun 20, 2018 at 9:15am PDT

The conference kicked off with a keynote by the JHipster's co-leads: Julien and Deepu.

Full house at #JHipsterConf @java_hipster #paris pic.twitter.com/nnZ6JmlXrW
— Deepu K Sasidharan (@deepu105) June 21, 2018

JHipster Conf 2018 keynote from Julien Dubois

During my talk, I had Jack join me on stage for an intro, and tried to give him a taste of public speaking in front of hundreds.

After a fabulous day at #JHipsterConf and a fun rooftop party at @ippon_technologies , Jack and I enjoyed a romantic dinner and a bit of Fête de la Musique. ??

A post shared by Matt Raible (@vwsforlife) on Jun 21, 2018 at 2:44pm PDT

My talk went well, with some successful and some failed demos. Hopefully people got the point that it’s cool to store your users outside of JHipster so you can share them between apps. I also tried to show that OAuth and OIDC are excellent for securing APIs. You can download my presentation from Add JHipster to Your JHipster Apps with OIDC or view it below.

I created a tutorial of the app I showed in my talk and published it to the Okta developer blog: Build a Photo Gallery PWA with React, Spring Boot, and JHipster. If you like React and OAuth, you're gonna love this guide!

Jack and I had a day in Paris after the conference, so we made the most of it. We hit the Eiffel Tower, hiked the stairs, and marveled at the view. After, we waited in a long line for The Catacombs and walked among the dead.

I had a wonderful time this week in Paris and at @jhipsterconf. Many thanks to the @java_hipster developers, community, @juliendubois, @deepu105, and @ippontech for making it all possible! #JHipsterConf pic.twitter.com/61ZfRZxg8G
— Matt Raible (@mraible) June 23, 2018

Kudos to the JHipster Community!

What a trip! It’s so much fun to be a part of JHipster’s thriving open source community. It’s not just the project itself; it’s all the projects we build upon, from Java to TypeScript to Spring Boot to Spring Data to Spring Security to Angular to React to webpack to Bootstrap. It’s a conglomeration of all of my favorite tools and open source developers encompassed in several awesome projects!

Life as an open source developer is pretty fun. I encourage you to get involved in open source too! I started way back in the early 2000s with Struts and Ant, and it’s done wonders for my career.

Viva La Open Source!

Why I prefer IntelliJ IDEA over Eclipse

2014-07-21T13:33:55-06:00

Over the last couple months, I've received a few emails asking why I prefer IntelliJ IDEA over Eclipse. They usually go something like this:

I keep seeing you recommending IntelliJ. I keep trying it intermittently with using Eclipse, but I feel like I'm missing something obvious that makes so many people think it's better. Granted having the usual plugins incorporated is nice, but other things like the build process and debugger sometimes seems a step back from Eclipse. Could you please blog a '10 reasons why I love IntelliJ' or point me to something that would clue me in?

I grew to love IntelliJ for a few reasons. It all started in 2006 when I decided to migrate AppFuse from Ant to Maven. Before that, I was a huge Eclipse fan (2002 - 2006). Before Eclipse, I used HomeSite, an HTML Editor to write all my Java code (1999-2002). Eclipse was the first IDE that didn't hog all my system's memory and was pleasant to work with.

The reason I started using IntelliJ in 2006 was because of it's multi-module Maven support. Eclipse's Maven support was terrible, and m2e hasn't gotten a whole lot better in recent years AFAIK.

Back then, I used to think everything should be built and run from the command line. A couple years later, I realized it was better to run tests and debug from an IDE. Now I'm more concerned with the ability to run tests and debug in an IDE than I am from the build system.

In 2009, I started doing a lot more front-end work: writing HTML, CSS and JavaScript. I also started digging into alternate languages for these: Jade, GWT, CoffeeScript, LESS, SASS - even Scala. I found IntelliJ's support, and plugins, to be outstanding for these languages and really enjoyed how it would tell me I had invalid JavaScript, HTML and CSS.

My original passion in software was HTML and JavaScript and I found that hasn't changed in the last 15 years. AFAIK, Eclipse still has terrible web tools support; it excels at Java (and possibly C++ support). Even today, I write most of my HTML code (for InfoQ and this blog) in IntelliJ.

In reality, it probably doesn't matter which IDE you use, as long as you're productive with it. Once you learn one IDE well, the way others do things will likely seem backwards. I'm so familiar with debugging in IntelliJ, that when I tried to use Eclipse's debugger a few weeks ago, it seemed backwards to me.

In a nutshell: the technologies I've worked with have been better embraced by IntelliJ. Has this happened to you? Have certain technologies caused you to use one IDE over another?

Using Grunt with AngularJS for Front End Optimization

2014-01-15T12:15:52-07:00

I'm passionate about front end optimization and have been for years. My original inspiration was Steve Souders and his Even Faster Web Sites talk at OSCON 2008. Since then, I've optimized this blog, made it even faster with a new design, doubled the speed of several apps for clients and showed how to make AppFuse faster. As part of my Devoxx 2013 presentation, I showed how to do page speed optimization in a Java webapp.

I developed a couple AngularJS apps last year. To concat and minify their stylesheets and scripts, I used mechanisms that already existed in the projects. On one project, it was Ant and its concat task. On the other, it was part of a Grails application, so I used the resources and yui-minify-resources plugins.

The Angular project I'm working on now will be published on a web server, as well as bundled in an iOS native app. Therefore, I turned to Grunt to do the optimization this time. I found it to be quite simple, once I figured out how to make it work with Angular. Based on my findings, I submitted a pull request to add Grunt to angular-seed.

Below are the steps I used to add Grunt to my Angular project.

Install Grunt's command line interface with "sudo npm install -g grunt-cli".
Edit package.json to include a version number (e.g. "version": "1.0.0").

Add Grunt plugins in package.json to do concat/minify/asset versioning:

    "grunt": "~0.4.1",
    "grunt-contrib-concat": "~0.3.0",
    "grunt-contrib-uglify": "~0.2.7",
    "grunt-contrib-cssmin": "~0.7.0",
    "grunt-usemin": "~2.0.2",
    "grunt-contrib-copy": "~0.5.0",
    "grunt-rev": "~0.1.0",
    "grunt-contrib-clean": "~0.5.0"

Run "sudo npm install" to install the project's dependencies.

Create a Gruntfile.js that runs all the plugins.

module.exports = function (grunt) {

    grunt.initConfig({
        pkg: grunt.file.readJSON('package.json'),

        clean: ["dist", '.tmp'],

        copy: {
            main: {
                expand: true,
                cwd: 'app/',
                src: ['**', '!js/**', '!lib/**', '!**/*.css'],
                dest: 'dist/'
            },
            shims: {
                expand: true,
                cwd: 'app/lib/webshim/shims',
                src: ['**'],
                dest: 'dist/js/shims'
            }
        },

        rev: {
            files: {
                src: ['dist/**/*.{js,css}', '!dist/js/shims/**']
            }
        },

        useminPrepare: {
            html: 'app/index.html'
        },

        usemin: {
            html: ['dist/index.html']
        },

        uglify: {
            options: {
                report: 'min',
                mangle: false
            }
        }
    });

    grunt.loadNpmTasks('grunt-contrib-clean');
    grunt.loadNpmTasks('grunt-contrib-copy');
    grunt.loadNpmTasks('grunt-contrib-concat');
    grunt.loadNpmTasks('grunt-contrib-cssmin');
    grunt.loadNpmTasks('grunt-contrib-uglify');
    grunt.loadNpmTasks('grunt-rev');
    grunt.loadNpmTasks('grunt-usemin');

    // Tell Grunt what to do when we type "grunt" into the terminal
    grunt.registerTask('default', [
        'copy', 'useminPrepare', 'concat', 'uglify', 'cssmin', 'rev', 'usemin'
    ]);
};

Add comments to app/index.html so usemin knows what files to process. The comments are the important part, your files will likely be different.

<!-- build:css css/app-name.min.css -->
<link rel="stylesheet" href="lib/bootstrap/bootstrap.min.css"/>
<link rel="stylesheet" href="lib/font-awesome/font-awesome.min.css"/>
<link rel="stylesheet" href="lib/toaster/toaster.css"/>
<link rel="stylesheet" href="css/app.css"/>
<link rel="stylesheet" href="css/custom.css"/>
<link rel="stylesheet" href="css/responsive.css"/>
<!-- endbuild -->
...

<!-- build:js js/app-name.min.js -->
<script src="lib/jquery/jquery-1.10.2.min.js"></script>
<script src="lib/bootstrap/bootstrap.min.js"></script>
<script src="lib/angular/angular.min.js"></script>
<script src="lib/angular/angular-animate.min.js"></script>
<script src="lib/angular/angular-cookies.min.js"></script>
<script src="lib/angular/angular-resource.min.js"></script>
<script src="lib/angular/angular-route.min.js"></script>
<script src="lib/fastclick.min.js"></script>
<script src="lib/toaster/toaster.js"></script>
<script src="lib/webshim/modernizr.min.js"></script>
<script src="lib/webshim/polyfiller.min.js"></script>
<script src="js/app.js"></script>
<script src="js/services.js"></script>
<script src="js/controllers.js"></script>
<script src="js/filters.js"></script>
<script src="js/directives.js"></script>
<!-- endbuild -->

A couple of things to note: 1) the copy task copies the "shims" directory from Webshims lib because it loads files dynamically and 2) setting "mangle: false" on the uglify task is necessary for Angular's dependency injection to work. I tried to use grunt-ngmin with uglify and had no luck.

After making these changes, I'm able to run "grunt" and get an optimized version of my app in the "dist" folder of my project. For development, I continue to run the app from my "app" folder, so I don't currently have a need for watching and processing assets on-the-fly. That could change if I start using LESS or CoffeeScript.

The results speak for themselves: from 27 requests to 5 on initial load, and only 3 requests for less than 2K after that.

	YSlow	Page Speed
No optimization	75 27 HTTP requests / 464K	55/100
Apache optimization (gzip and expires headers)	89 initial load: 26 requests / 166K primed cache: 4 requests / 40K	88/100
Apache + concat/minified/versioned files	98 initial load: 5 requests / 136K primed cache: 3 requests / 1.4K	93/100

Update: Andreas Andreou has a nice tip on how to reduce the LOC in this example.

Add "matchdep" as a dependency in package.json (or run "sudo npm install matchdep --save-dev").
```
"matchdep": "~0.3.0"
```

Replace all the grunt.loadNpmTasks(...) calls with the following:

require('matchdep').filterDev('grunt-*').forEach(grunt.loadNpmTasks);

Thanks Andreas!

Happy 10 Year AppFuse!

2013-04-05T08:56:45-06:00

10 years ago yesterday, I released the first version of AppFuse. It started with XDoclet generating ActionForms from POJOs and became very popular for Struts developers that wanted to use Hibernate. The project's popularity peaked in 2006, as you can see from the mailing list traffic below.

It's possible the decrease in traffic is because we re-wrote everything to be based on Maven. It's also possible it was because of more attractive full-stack frameworks like Grails and Rails. However, the real reason is likely that I stopped working on it all the time due to getting a divorce becoming an awesome dad.

Below is a timeline of how the project evolved over its first 4 years.

AppFuse has been a great project for me to work on and it's been a large source of my knowledge about Java, Web Frameworks, Spring, Hibernate - as well as build systems like Ant and Maven. We started with CVS, moved to SVN and now we're on GitHub. We've experienced migrating from Tapestry 4 to Tapestry 5 (thanks Serge Eby!), upgrading to JSF 2 and enjoyed the backwards compatibility of Spring and Struts 2 throughout the years. We've also added REST support, a Web Services archetype and kept up with the latest Spring and Hibernate releases.

Last year, we added Bootstrap and jQuery as foundational front-end frameworks. For our next release, we're switching to PrimeFaces, adding Wicket and changing from jMock to Mockito. Most of these changes are already in source control, we just need to polish them up a bit and add AMP support. I hope to release 3.0 before the bus is done.

Thanks to all the enthusiastic users of and contributors to AppFuse over the years. It's been a great ride!

Refreshing Taleo's UI with HTML5, Twitter Bootstrap and CSS3

2012-08-20T12:27:21-06:00

Back in December, I wrote about what I've been working on at Taleo. Shortly after finishing up the Profile Picture, Talent Card and Org Chart features for TBE, I spent two weeks doing page speed optimization. By following Web Performance Best Practices, I was able to make the TBE application twice as fast and improve its score into the low 90s.

Next, I started working on a new project - refreshing the UI. Nick, the Lead UX Designer at Taleo (at the time), had developed a number of mockups and presented it to the developers and product folks in early November. I listened to a WebEx of that meeting and learned that everyone thought it'd take 6-9 months to complete the work. They figured they could release the new design in Q3 2012.

Since I like to provide high-value for my clients, I offered to help with the redesign and do a spike to help estimate. They agreed it'd be a good use of my time and I started working on it the week before Christmas. Since I'd used Twitter Bootstrap for my Play More! app, I recommended we use it as a foundation of the redesign. They agreed and I went to work. By the end of the week, I'd made good progress and told them I thought the redesign was possible in 2-3 months (including QA and cross-browser compatibility).

When I came back to work in January, we decided to split the redesign into two phases. Rather than moving elements around and introducing new features, we decided to do that in the 2nd phase. The 1st phase would entail simply re-skinning the existing UI, with minimal HTML changes. I spent a week refining my spike and integrating it into a branch. The next week, I switched images from individual images to CSS sprites. Next, I implemented a new theming system with different colors/icons and got everything looking good in Chrome, Safari and IE8/9.

The result is something I'm quite proud of. IE8 doesn't have the rounded corners (via border-radius), but it still looks good. Forms look much better thanks to Bootstrap's styling and even jQuery UI's widgets look good thanks to jQuery UI Bootstrap. I did have to override quite a few Bootstrap styles in the process, but the result is something that doesn't look too bootstrappy.

One technique I found to be extremely useful during this process was to pair with Nick (the designer) as mentioned in Building Twitter Bootstrap. At one point, when we were trying to refine slight nuances and spacing in the UI, I paired with the Product Manager and found this to be a real time-saving effort as well.

Taleo's UI Refresh project has been a great experience for me in sharpening my CSS skills. I used quite a bit of child and sibling selectors, which work great in all the browser's we're supporting. Also, by using CSS sprites and colors (vs. images), I was able to get the manual theme-creation process down to around 15 minutes. After getting the manual process greatly reduced, I wrote a Theme Generator (based on Ant, LESS and wro4j) and got it down to mere minutes. I found Sprite Cow to be an invaluable resources for working with CSS sprites.

Below are some before and after shots of what we've been able to accomplish in the first quarter of this year.

I originally wrote this post at the end of January. We ran into some stumbling blocks shorty after its original composition: Nick (the designer) moved onto greener pastures and Oracle bought Taleo. What I didn't expect when I wrote this was to spend the next two months fixing slight bugs that occurred with spacing, alignment and dependent applications I didn't know about at the time. And then there was IE7. We didn't realize we needed to support it until mid-March. Then it took us around a month to make it all work good enough.

The good news is the UI Refresh was released a few months ago and seems to be humming along just fine. Sure, there were slight nuances and customizations we had conflicts with (clashing CSS classes), but overall it seems to have gone well. I can't thank the Bootstrap developers enough for motivating us to move to HTML5 and CSS3. Also, cheers to the excellent co-workers that helped make this happen: Murray Newton (Product Manager) and Vladimir Bazarsky. I couldn't have done it without you guys.

What have I been working on at Taleo?

2011-12-09T12:57:36-07:00

2011 has been a year of great clients for me. I started working with O.co and very much enjoyed my time there, especially on powder days in Utah. The people were great, the contract was great (no end date), but the work was not my forte. I was on a project to modularize the main shopping site's codebase, which involved mostly refactoring. By refactoring, I mean creating new Maven projects, modifying lots of pom.xml files and literally moving files from one directory to another. IntelliJ made this easy, the hard part was refactoring tests, moving from EasyMock to Mockito and splitting classes into interfaces and implementations where appropriate. As a developer who likes developing UIs and visually seeing my accomplishments, the project wasn't that exciting. However, I knew that it was strategically important to O.co, so I didn't complain much.

In mid-May, I received a LinkedIn message from the Director of Software Engineering at Taleo.

This is OB, I am the Director of Software Engineering at Taleo. We are the 2nd largest Software as a Service company. I am building a new specialist UI team that will take the product to the next level. I am looking for someone to lead this initiative. If you are interested to have a chat about it, please let me know.

At that time, I'd never heard of Taleo and quickly recommended they not hire me.

This probably isn't the best position for me. While I am a good leader, I'm not willing to relocate from Denver. I've found that leaders usually do best when face-to-face with their developers.

This conversation continued back-and-forth where I explained how I wasn't willing to go full-time and I didn't want to leave Overstock. In the end, OB was persistent and explained how the position would entail lots of UI work and wouldn't require me to travel much. Our negotiations trailed off in June and resumed in July after I returned from vacation in Montana. Shortly after, we met each other's expectations, agreed on a start date and I started working at Taleo in early September.

When I started, there were three features they wanted to add to to Taleo Business Edition: Profile Pictures, Talent Cards and Org Charts. They knew the schedule was tight (8 weeks), but I was confident I could make it happen. At first, I groaned at the fact that they were using Ant to build the project. Then I smiled when I learned they'd standardized on IntelliJ and set things up so you could do everything from the IDE. After using Maven for many years, this setup has actually become refreshing and I rarely have to restart or long for something like JRebel. Of course, a new kick-ass laptop and awesome IDE make it so I rarely wait for anything to happen.

To give you a taste of how I implemented each of these new features in 8 weeks, I've broken them into sections below.

Profile Pictures
Adding profile pictures was a pretty simple concept, one you see on my social networking sites today. I needed to give users the ability to upload a JPEG or PNG and crop it so it looked good. The uploading was a pretty straightforward process and I used a lot of internal APIs to grab the file from the request and save it to disk. The more difficult part was scaling the image to certain dimensions on upload (to save space) and allowing users to crop it after.

Most of Taleo Business Edition (TBE) is written in good ol' servlets and JSPs, with lots of scriptlets in their JSPs. When I saw the amount of HTML produced from Java, I laughed out loud and cringed. Soon after, I breathed a sigh of relief when I learned that any new features could be written using FreeMarker templates, which IntelliJ has excellent support for.

For image resizing on upload, I used Chris Campbell's Image.getScaledInstance() tutorial. For creating thumbnails, I used a combination of scaling, getSubimage() and the Java Image I/O API. I made sure to write to BufferedOutputStream for scalability. For cropping images client-side, I used jQuery UI's Dialog and Jcrop, the jQuery image cropping plugin. Below is a screenshot of what the cropping UI looks like:

Talent Cards
Talent Cards were a whole different beast. Not only did they need to display profile pictures, they also needed to contain contact information, work history and a number of other data points. Not just for employees, but for candidates as well. They also needed to be rendered with tabs at the bottom that allowed you to navigate between different data sections.

I'll admit, most of the hard work for this feature was done by the server-side developers (Harish and Vlad) on my team. Vlad built the tabbed interface and Harish built the administrative section that allows you to add/remove/sort fields, as well as show and hide certain tabs. I performed most of my magic with jQuery, its clueTip plugin and good ol' CSS. I was particularly thankful for CSS3 and its border-radius, box-shadow and Justin Maxwell's tutorial on CSS String Truncation with Ellipsis. I used DWR to fetch all the data from the server using Ajax.

Talent Cards are a slick feature in TBE 11.5 and I think they're a great way to see a lot of information about someone very quickly. If you enable them for your company, you'll be able to mouse over any employee or candidate's names and see their information.

Org Chart
The last feature I completed in this 8-week sprint was creating an organization chart. For this, I was given a rough prototype based on Caprica Software's JQuery/CSS Organisation Chart. When I received it, it had all kinds of cool CSS 3 transformations (like this one), but they only worked in Safari and Chrome. I ended up removing the transformations and adding the ability to navigate up and down the org tree with Ajax (we currently only show three levels at a time).

The Org Chart feature also allows you to see how many direct/indirect reports an employee has, as well as access their Talent Card by hovering over their name. It's one of my favorite features because it's so visual and because it builds upon all the other features we've built.

Summary
As you might've guessed by now, I've been having a lot of fun doing UI development over the last few months. While I seem to have a knack for backend Java development, I enjoy developing UIs a lot more. The smile you see on people's faces during demos is priceless. I can't help but think this kind of thing contributes greatly to my developer happiness. All these features will be in next week's release of TBE and I couldn't be happier.

If you'd like to work on my team at Taleo (or even take over my current role as UI Architect), please drop me a line. If you live near their headquarters (Dublin, CA), it'd also be great to see you at the next Silicon Valley Spring User Group meetup. I'll be speaking about What's New in Spring 3.1 on February 1st.

Integrating HTML5 Boilerplate with Scalate and Play

2011-09-28T08:49:35-06:00

HTML5 Boilerplate is a project that provides a number of basic files to help you build an HTML5 application. At its core, it's an HTML template that puts CSS at the top, JavaScript at the bottom, installs Chrome Frame for IE6 users and leverages Modernizr for legacy browser support. It also includes jQuery with the download. One of the major benefits of HTML5 Boilerplate is it ships with a build system (powered by Ant) that concatenates and minimizes CSS and JS for maximum performance. From html5boilerplate.com:

Boilerplate is not a framework, nor does it prescribe any philosophy of development, it's just got some tricks to get your project off the ground quickly and right-footed.

I like the idea of its build system to minify and gzip, but I'd probably only use it if I was working on a project that uses Ant. Since I'm using it in a Play project, the whole Ant build system doesn't help me. Besides, I prefer something like wro4j. Wro4j allows you to specify a group of files and then it compiles, minimizes and gzips them all on-the-fly. As far as I know, Play doesn't have any support for Servlet Filters, so using wro4j in Play is not trivial.

The good news is Play has a GreenScript module that contains much of the wro4j functionality. However, since I'm using Scalate in my project, this goodness is unavailable to me. In the future, the Scalate Team is considering adding better wro4j, JavaScript and CSS integration. In the meantime, I'm going to pretend I don't care about concatenation and minimization and trundle along without this feature.

To add HTML5 Boilerplate to my Play project, I performed the following steps:

Downloaded the 2.0 Zipball.

Copied all the static files to my project. Below are the commands I used (where $boilerplate-download is the expanded download directory and ~/dev/play-more is my project):

cd $boilerplate-download
cp 404.html ~/dev/play-more/app/views/errors/404.html
cp *.png ~/dev/play-more/public/.
cp crossdomain.xml ~/dev/play-more/public/.
cp -r css ~/dev/play-more/public/stylesheets/.
cp favicon.ico ~/dev/play-more/public/.
cp humans.txt ~/dev/play-more/public/.
cp -r js/libs ~/dev/play-more/public/javascripts/.
cp robots.txt ~/dev/play-more/public/.

Copied the index.html to ~/dev/play-more/app/templates/layouts/default.jade and modified it to use Jade syntax. Since I downloaded the comments-heavy version, I modified many of them to be hidden in the final output.

-@ val body: String 
-@ var title: String = "Play More"
-@ var header: String = ""
-@ var footer: String = ""
!!! 5
/ paulirish.com/2008/conditional-stylesheets-vs-css-hacks-answer-neither/ 
<!--[if lt IE 7]> <html class="no-js ie6 oldie" lang="en"> <![endif]-->
<!--[if IE 7]>    <html class="no-js ie7 oldie" lang="en"> <![endif]-->
<!--[if IE 8]>    <html class="no-js ie8 oldie" lang="en"> <![endif]-->
-# Consider adding an manifest.appcache: h5bp.com/d/Offline 
<!--[if gt IE 8]><!--> <html class="no-js" lang="en"> <!--<![endif]-->
head
  meta(charset="utf-8")

  -# Use the .htaccess and remove these lines to avoid edge case issues. More info: h5bp.com/b/378 
  meta(http-equiv="X-UA-Compatible" content="IE=edge,chrome=1")

  title=title
  meta(name="description" content="")
  meta(name="author" content="Matt Raible ~ matt@raibledesigns.com")

  -# Mobile viewport optimized: j.mp/bplateviewport 
  meta(name="viewport" content="width=device-width,initial-scale=1")

  -# Place favicon.ico and apple-touch-icon.png in the root directory: mathiasbynens.be/notes/touch-icons

  -# CSS: implied media=all
  link(rel="stylesheet" href={uri("/public/stylesheets/style.css")})
  -# end CSS

  -# More ideas for your <head> here: h5bp.com/d/head-Tips 
  -#
    All JavaScript at the bottom, except for Modernizr / Respond.
    Modernizr enables HTML5 elements & feature detects; Respond is a polyfill for min/max-width CSS3 Media Queries
    For optimal performance, use a custom Modernizr build: www.modernizr.com/download/ 

  script(type="text/javascript" src={uri("/public/javascripts/libs/modernizr-2.0.6.min.js")})
body
  #container
    header = header
    #main(role="main")
      != body
    footer = footer

  -# JavaScript at the bottom for fast page loading 
  
  / Grab Google CDN's jQuery, with a protocol relative URL; fall back to local if offline 
  script(type="text/javascript" src="//ajax.googleapis.com/ajax/libs/jquery/1.6.2/jquery.min.js")
  :javascript
    window.jQuery || document.write('<script src={uri("/public/javascripts/libs/jquery-1.6.2.min.js")}><\/script>')

  -# Change UA-XXXXX-X to be your site's ID 
  :javascript
    window._gaq = [['_setAccount','UA-25859875-1'],['_trackPageview'],['_trackPageLoadTime']];
    Modernizr.load({
      load: ('https:' == location.protocol ? '//ssl' : '//www') + '.google-analytics.com/ga.js'
    });

  -# Prompt IE 6 users to install Chrome Frame. Remove this if you want to support IE 6. 
  -# http://chromium.org/developers/how-tos/chrome-frame-getting-started 
  /[if lt IE 7]
    script(src="//ajax.googleapis.com/ajax/libs/chrome-frame/1.0.3/CFInstall.min.js")
    :javascript
      window.attachEvent('onload',function(){CFInstall.check({mode:'overlay'})})
        
!= "</html>"

Next, I had to add support for layouts to my homegrown Scalate support. I did this by specifying a layoutStrategy when initializing the TemplateEngine. From play-more/app/controllers/ScalateTemplate.scala:
```
engine.classLoader = Play.classloader
engine.layoutStrategy = new DefaultLayoutStrategy(engine, 
  Play.getFile("/app/templates/layouts/default" + scalateType).getAbsolutePath)
engine
```

That's it! Now I have HTML5 Boilerplate integrated into my Play/Scalate/Jade application. To set the title and header in my index.jade, I simply added the following lines at the top:

- attributes("title") = "Counting"
- attributes("header") = "HTML5 Rocks!"

CoffeeScript Tip
Yesterday, I mentioned that I was having issues getting CoffeeScript to work with Scalate and that I was going to try and get the in-browser compiler working. First of all, reverting to Scalate 1.4.1 didn't work because there is no CoffeeScript support in 1.4.1. So I stayed with 1.5.2 and used PandaWood's Running CoffeeScript In-Browser Tutorial. I copied coffee-script.js to ~/dev/play-more/public/javascripts/libs and added a reference to it in my default.jade layout:

-# JavaScript at the bottom for fast page loading 
script(type="text/javascript" src={uri("/public/javascripts/libs/coffee-script.js")})

Then I was able to write CoffeeScript in a .jade template using the following syntax:

:plain
  <script type="text/coffeescript">
    alert "hello world"
  </script>

Summary
If you've integrated HTML5 Boilerplate into your Play application, I'd love to hear about it. Now that I have all the infrastructure in place (Jade, CoffeeScript, HTML5 Boilerplate), I'm looking forward to getting some development done. Who knows, maybe I'll even come up with my own Play Un-Features That Really Irk My Inner Geek.

Upgraded to Apache Roller 5.0, RC4

2011-03-03T11:39:37-07:00

Last Sunday, Dave Johnson released Apache Roller 5.0, RC4. Since I'm an Apache Roller committer, and I've been seeing issues with comments throwing exceptions on this site, I decided to upgrade. In doing so, I discovered a number of issues. Hopefully by documenting them here, you'll be able to upgrade from Roller 4 to Roller 5 without any issues.

To upgrade, I took a snapshot of my existing site and database and copied them locally. After getting everything setup locally (importing existing database and upgrading it), I started Tomcat and began solving problems.

Database settings - JNDI vs. Properties
With Roller 4, I configured by database settings in a ROOT.xml so they'd be read using JNDI. With Roller 5, I got the following error when I tried to do this.

<openjpa-2.0.1-r422266:989424 fatal user error> org.apache.openjpa.persistence.ArgumentException:
A JDBC Driver or DataSource class name must be specified in the ConnectionDriverName property.
       at org.apache.openjpa.jdbc.schema.DataSourceFactory.newDataSource(DataSourceFactory.java:76)

I was able to get around this issue by adding the following to my roller-custom.properties:

database.configurationType=jdbc
database.jdbc.driverClass=com.mysql.jdbc.Driver
database.jdbc.connectionURL=jdbc:mysql://localhost/rollerdb
database.jdbc.username=root
database.jdbc.password=
mail.configurationType=properties
mail.hostname=localhost

After making this change, I received an error when Planet tried to startup:

ERROR 2011-03-02 09:56:08,502 DatabaseProvider:errorMessage - ERROR: unable to obtain database connection. 
Likely problem: bad connection parameters or database unavailable.
FATAL 2011-03-02 09:56:08,502 RollerContext:contextInitialized - Roller Planet startup failed during app preparation
org.apache.roller.planet.business.startup.StartupException: ERROR: unable to obtain database connection. 
Likely problem: bad connection parameters or database unavailable.

I don't remember why I enabled planet, but turning it off in roller-custom.properties seemed to solve the problem.

planet.aggregator.enabled=false

Password Encyrption
The next thing I tried to do was login. When this didn't work, I figured it must be related to password encryption. With Roller 4, I had to have "passwds.encryption.enabled=true" in roller-custom.properties. In Roller 5, I also had to add the encryption algorithm.

passwds.encryption.algorithm=SHA

GZip Compression
In November 2009, I optimized this site and used Roller's CompressionFilter and wro4j to gzip and concatenate JavaScript and CSS. With Roller 4, I used the CompressionFilter to compress *.css and *.js instead of using Wro4J's built-in gzip compression. The Roller 5 CompressionFilter seems to have issues with wro4j, so I had to disable it for *.css and *.js and use wro4j instead.

At this point, I figured I was good to go, so I zipped up my local WAR and scp'ed it to raibledesigns.com. I stopped Tomcat and attempted to upgrade my production MySQL database (version 3.23.56). Below is the error I received.

$ mysql -u raible -p raible < 400-to-500-migration.sql
Enter password:
ERROR 1064 (00000) at line 42: You have an error in your SQL syntax near 'as w set
   lastmodified = lastmodified,
   datecreated = datecreated,
   cr' at line 1

At this point, I figured my database might be slightly hosed, but since it was simply creating tables, I was probably OK. I restarted Tomcat and left the old version in place while I waited for a MySQL 5 database instance from my hosting provider, KGB Internet. Once I got the new instance, I imported my backed-up database, ran the upgrade script and everything worked just peachy.

I generally upgrade Roller by coping the new codebase over my old one. This is because I have a lot of symlinks and other files in my "ROOT" directory and like to keep those. In doing this, I found I had to do a couple things after copying everything over:

Delete WEB-INF/lib and recopy from RC4's WEB-INF/lib.
Delete WEB-INF/classes and recopy from RC4's WEB-INF/classes.

I then experienced some issues with JARs not being present for Roller's JSPWikiPlugin. I enabled this long ago, but don't use it anymore. However, to keep old posts still working, I wanted to enable it. The downloads for the plugin seem to be gone, but luckily I found a copy and put all the JARs into my WEB-INF/lib directory.

After starting Tomcat and browsing around a bit, I discovered two more issues:

Search doesn't seem to work. For example, there are no results for jQuery.
My Archives page's calendar didn't work. It showed the following:
```
$calendarModel.showWeblogEntryCalendarBig($weblog, $cat)
```

I was able to fix issue #2 by changing #showBigWeblogCalendar() to the following.

#showWeblogEntryCalendarBig($model.weblog "nil")

The first issue with search seems to remain.

If you notice any other issues on this site, please let me know. I'll try to get them fixed asap.

Update: I entered an issue for my search problem in Roller's JIRA. I also managed to figure out that the problem is due to the old version of oscache that's needed by the JSPWiki plugin. Hopefully we can get the plugin upgraded to avoid this issue for other users.

Software Quality: The Quest for the Holy Grail?

2010-03-17T15:00:46-06:00

This afternoon, I attended a session on software quality by Jesper Pedersen at TSSJS. Jesper is a Core Developer at JBoss by Red Hat. He's the project lead of JBoss JCA, Tattletale, Papaki and JBoss Profiler 2. He's also currently the chairman of the Boston JBoss User Group. In this session, Jesper hopes to define basic requirements for a development environment and offer ideas on how to clean up a messy project.

Is software quality a friend or a foe? By implementing software quality processes, are you introducing unnecessary overhead? Development platforms are different today. We write a lot more business-specific code. We depend on standard frameworks for the core functionality. We depend on vendors to implement the standards correctly. We also depend on vendors to provide the necessary integration layer.

Since the platform is now a large slice of the pie, we must make sure we know where the issue is located. We must have proper integration tests; we must manage dependencies. Today, we must treat dependencies as if they are part of the application.

Defining the platform for your project helps narrow down the dependencies for your project. The platform is composed of corporate guidelines, standards, vendors and backend systems that you have to integrate with. Documentation is key for a successful project. Key documents types: User Guide, Developer Guide, API Guide, Architect Design, Implementation and Test.

It helps to define a project-wide configuration management system. Define a code-formatting guide will add consistency in your source tree. Also make sure you have separate build, test and execution environments. Use a Maven repository for your dependencies; both to support your project's artifacts as well as vendor artifacts.

"Maven today is an industry standard." -- Jesper Pederson

Define your tool chain as you would for your application. Back your Maven repository with SCM tools like Subversion or Git. For testing, use JUnit (unit testing), Corbertura (test coverage) and Hudson (continuous integration). Furthermore, you can add Checkstyle and Findbugs to verify coding conventions and find basic issues with code.

For the build environment, you need to make sure your dependency metadata is correct. Also, make sure you use the best practices for your given build tool. For example, with Maven and Ivy, it's a good idea to extract the version numbers into a common area of your pom.xml/build.xml so you can easily view all the versions in use. After you've done this, you can externalize the version information from the environment. Watch out for transitive dependencies as they can be tricky. Make sure you know what gets pulled in. Use enforcers to approve/ban dependencies or turn it off (Ivy). You can also vote for MNG-2315. Finally, snapshot dependencies are evil: define your release process so that releases are easy.

What can you do if your project is already a mess? Signs that your project is a mess: you look at your platform as a big black box, you use different dependencies than your deployment platform or you don't have integration tests for sub-systems or dependencies. To fix this, you can use a tool to get an overview of the entire project. Enter Tattletale.

Tattletale can give you an overview of your dependencies (Ant and Maven integration). It's a static analysis tool that doesn't depend on metadata, scanning your class files instead. Using Tattletale, you can produce a number of reports about your dependencies, what they're dependent on and what's dependent on you.

To maintain the lead in your project, make sure to define a checklist for each stage of your development cycle. Do reviews on documentation, architecture, component design and code. Enforce your rules of your project with your build system.

Jesper's final thoughts:

Maintaining dependencies for a software project can be a tricky task.
Using an Open Source platform as the foundation will ease the investigation of issues and increase trust.
Defining a project-wide tool chain is key.
Enforce all the rules on the project (better up-front than "fixing it" afterwards)

As Dusty mentioned, this session has a lot of good (basic) information, but there wasn't much new stuff. My team is using many of the technologies and practices that Jesper has mentioned. I guess that's validation that we're doing it right. I've heard of Tattletale, but never had a need for it since I haven't been on any "messy" projects recently.

My Future of Web Frameworks Presentation

2010-02-26T08:55:39-07:00

Earlier this week, I tweeted about a history of web frameworks timeline I created for my upcoming Future of Web Frameworks talk at TSSJS Vegas 2010. I immediately received a lot of feedback and requests for adding new frameworks and releases. The image below is the result of that Twitter conversation. Thanks to everyone who contributed.

Back in November, I wrote about my proposals for TSSJS. I've been thinking a lot about web frameworks lately and I can't help but think we live in a very exciting time. As a Java developer, I've been exposed to one of the most vibrant language ecosystems on the planet. As Tim Bray talks about, the Java Platform has 3 legs: the language, the virtual machine and a huge, immense library of APIs (both in the JDK and in open source libraries). The diagram below is something I created based on Tim's podcast.

Tim says, "One of those legs is replaceable and that's the language." And he's right, there's many Java.next languages that run efficiently on the JVM. This is one of the most exciting parts of being a Java web developer today. There's many proven web frameworks and languages that you can pick to build your next web application.

The best part is many of the best web frameworks run on the JVM. Not only that, but the best code editors are the IDEs that you're familiar with and have grown to love. Furthermore, much of the literature for Java.next languages is written for Java developers. As someone who knows Java, you have wealth of web frameworks and languages just waiting for you to learn them.

To create my presentation on the future of web frameworks, I followed the outline I posted previously. I plan on explaining the evolution and history of web frameworks and how we got to where we are today. From there, I'll be speculating on what web applications we'll be developing in the future. Finally, I'll touch on the necessary features of web frameworks that will allow us to develop these applications.

Of course, I haven't actually presented this talk yet, so it's likely to change in the coming weeks before the conference. The good news is this gives you the opportunity to provide constructive criticism on this presentation and help make it better. I realize that a presentation rarely represents the conversation that takes place during a conference. However, I believe it can portray the jist of my thinking and lead to a meaningful conversation in the comments of this post. Below is the presentation I created - thanks in advance for any feedback.

For those who will be joining me at TSSJS ... it's gonna be a great show. St. Patrick's Day in Vegas, what more could you ask for?

Update: This article has been re-posted on Javalobby and contains additional community feedback in the comments.

What's your preferred development infrastructure stack?

2010-01-12T21:54:46-07:00

Over the years, I've used many different source control systems, wikis, bug trackers and continuous integration servers. On many projects, I've been responsible for recommending and helping to install these systems. For the most part, they've often been disparate, meaning there wasn't a whole lot of integration between the various applications. Here's a list of all the different systems I've used:

Source Control Systems
- CVS
- StarTeam
- Subversion
Source Viewers
- FishEye
- Sventon
- Trac
- ViewVC
Wikis
- Confluence
- MediaWiki
- JSPWiki
- Trac
Bug Trackers
- Bugzilla
- JIRA
- StarTeam
- Trac
Continuous Integration Servers
- Bamboo
- Continuum
- CruiseControl
- Hudson
Mailing Lists / Forums
- A private Google Group
- Jive Forums
- Mailman

I believe all of these applications are useful in supporting an efficient development process. When clients have asked me to help them build this type of infrastructure, I've often asked if they wanted to pay for it or not. If not, I'd recommend Trac (since it has a wiki, source viewer and bug tracker all-in-one) and Hudson. If they were willing to pay, I'd recommend the Atlassian Suite (Confluence, JIRA and Bamboo).

These stacks all seem to work pretty well and the Atlassian Suite certainly works great for AppFuse and other open source projects. However, I recently had the pleasure of working at Chordiant Software where we used Chordiant Mesh to collaborate and develop software. Their Mesh system is powered by Jive Clearspace and provides a wealth of tools for each project, including a dashboard, discussions, documents, notifications and widgets providing status + links to JIRA and Bamboo.

Even though Clearspace's rich text editor caused me some early frustration, I really enjoyed the fact that a solid development infrastructure existed. It made it much easier to collaborate, document and execute our development process. I realize that it's difficult to build and maintain a custom development infrastructure stack. Chordiant had a whole team that developed, enhanced and supported their environment. But that doesn't mean it's impossible and not worth striving for.

I think there's a number of best-of-breed applications you can use to build a sweet development infrastructure stack.

Source Control: Git
Source Viewer: FishEye
Wiki: Jive SBS
Bug Tracker: JIRA
Continuous Integration: Hudson

I've only used Git for a few weeks, but I can easily tell it's better than Subversion. I don't think it's easy to convince companies to switch their source control system, so it's probably not worth arguing if you're already using Subversion. I can also envision using Confluence instead of Jive SBS, but then you lose forum support and have to use something like Mailman or Google Groups. JIRA Studio looks close to my dream stack, except it doesn't support Git or a forum + mailing list system.

What is your preferred development infrastructure stack? Why?

A Letter to the AppFuse Community

2009-11-04T00:17:17-07:00

The last AppFuse release was way back in May 2008. Many folks have asked when the next release would be ever since. Often, I've said "sometimes this quarter", but obviously, that's never happened. For that, I apologize.

There are many reasons I haven't worked on AppFuse for the past 18 months, but it mostly comes down to the fact that I didn't make time for it. The good news is I'm working on it again and will have a release out sometime this month. Unfortunately, it probably won't be a 2.1 final release, but there's so many things that've changed, I feel like a milestone release is a good idea. Here's a brief summary of changes so far:

Changed archetypes to include all source and tests for the "webapp" portion of the application. No more warpath plugin, merging wars and IDE issues. Using "mvn jetty:run" should work as expected.
Moved from Spring XML to Annotations.
AppFuse Light converted to Maven modules and now depends on AppFuse's backend.
Published easier to use archetype selection form in the QuickStart Guide.
Published archetype selection form for AppFuse Light. I do plan on combining these forms as soon as I figure out the best UI and instructions for users to choose AppFuse or AppFuse Light.
Upgraded all libraries to latest released versions (Spring 3 hasn't had a final release yet).
Upgraded to Tapestry 5 thanks to Serge Eby. I still need to complete tests and code generation for tests.
Added Compass support thanks to a patch from Shay Banon.
Upgraded from XFire to CXF for Web Services.
Moved Maven repository to Sonatype's OSS Repository Hosting for snapshots and releasing to Maven Central. There are no longer any AppFuse-specific artifacts, all are available in central.

I realize there's many full-stack frameworks that do the same thing as AppFuse with less code. Examples include Ruby on Rails, Grails, Seam, Spring Roo and the Play framework. However, there seems to be quite a few folks that continue to use AppFuse and it stills serves the community as a nice example of how to integrate frameworks. Furthermore, it helps me keep up with the latest framework releases, their quirks and issues that happen when you try to integrate them. In short, working on it helps me stay up to speed with Java open source frameworks.

For those folks that like the 1.x, Ant-based version of AppFuse, there will not be a 1.9.5 release. I know I promised it for years, but it's simply something I will not use, so I'd rather not invest my time in it. I'm sorry for lying to those that expected it.

So what's the future of AppFuse? Will it continue to integrate web frameworks with Spring and popular persistence frameworks? Possibly, but it seems more logical to align it with the types of Ajax + REST applications I'm creating these days. I'm currently thinking AppFuse 3.0 would be nice as a RESTful backend with GWT and Flex UIs. I might create the backend with CXF, but it's possible I'd use one of the frameworks mentioned above and simply leverage it to create the default features AppFuse users have come to expect.

More than anything, I'm writing this letter to let you know that the AppFuse project is not dead and you can expect a release in the near future.

Thanks for your support,

Matt

Running Hosted Mode in GWT Libraries (when using Maven)

2009-11-03T09:37:07-07:00

Earlier this year, I wrote about Modularizing GWT Applications with GWT-Maven. Fast forward 8 months and I'm still working with GWT and using this same technique. However, this time I'm working with the Maven GWT Plugin from Codehaus. In my last post, I wrote:

The results of modularizing your application are beneficial (shared code) and detrimental (you have to mvn install gwt-core whenever you make changes in shared classes). If you know of a way to configure the gwt-maven plugin to read sources from both gwt-core and gwt-webapp in hosted mode, I'd love to hear about it.

The good news is I found a solution for this, using the Builder Helper Maven Plugin. The GWT Maven Plugin's Productivity tip for multi-project setup has more information on how to configure this (note: we use IntelliJ and Eclipse on my project and did not need to configure this in a profile).

All was fine and dandy with this configuration until I wanted to be able to run hosted mode to develop/test everything in my library before including it in my main project. Luckily, you can still run mvn gwt:run on a JAR project. However, when you configure your pom.xml so sources are included in your JAR, you run into an issue: your *.java files will be copied to war/WEB-INF/classes and hosted mode will use these files as source rather than the ones you're editing in src/main/java.

To solve this, I changed my pom.xml to do two things:

Only copy resources right before packaging (in the test phase).
When packaging is complete, delete the *.java files from war/WEB-INF/classes (using Ant).

Below is the XML I used to make this possible. Please let me know if you have a way to simplify this configuration.

<plugin>
    <artifactId>maven-resources-plugin</artifactId>
    <version>2.4.1</version>
    <executions>
        <execution>
            <phase>test</phase>
            <goals>
                <goal>copy-resources</goal>
            </goals>
            <configuration>
                <outputDirectory>${project.build.outputDirectory}</outputDirectory>
                <resources>
                    <resource>
                        <directory>src/main/java</directory>
                    </resource>
                    <resource>
                        <directory>src/main/resources</directory>
                    </resource>
                </resources>
            </configuration>
        </execution>
    </executions>
</plugin>
<plugin>
    <artifactId>maven-antrun-plugin</artifactId>
    <version>1.3</version>
    <executions>
        <execution>
            <phase>package</phase>
            <goals>
                <goal>run</goal>
            </goals>
            <configuration>
                <tasks>
                    <delete>
                        <fileset dir="${project.build.outputDirectory}" includes="**/*.java"/>
                    </delete>
                </tasks>
            </configuration>
        </execution>
    </executions>
</plugin>

This solution seems to work pretty well. As far as developing your library in hosted mode, you'll need to configure two *.gwt.xml files, one that doesn't have an <entry-point> defined and one that does. Configure the one with the entry point as the <module> in your gwt-maven-plugin configuration.

As a side note, I found a few issues with the 1.1 version of the Maven GWT Archetype. Below are the steps I used to fix these issues and upgrade to GWT 1.7.0 (I realize 1.7.1 is out, but gwt-dev-1.7.1-mac.jar doesn't exist in Maven central).

First, create a new project by running the following from the command line:

mvn archetype:generate \
  -DarchetypeGroupId=org.codehaus.mojo \
  -DarchetypeArtifactId=gwt-maven-plugin \
  -DarchetypeVersion=1.1 \
  -DgroupId=com.yourcompany \
  -DartifactId=gwt-project -Dversion=1.0-SNAPSHOT -B

After creating the project, you'll need to modify the pom.xml as follows:

Change the gwt-maven-plugin's version to 1.1.
Change the ${gwtVersion} property to 1.7.0.
Add <runTarget>Application.html</runTarget> to the <configuration> element of the plugin.
Move Application.html and web.xml so they're under the "war" directory.
Update Application.html to prepend the GWT module name in the <script> tag.

I hope these instructions help you create modular GWT projects with Maven. This setup is working great on my current project.

How to use GWT 2.0 with Maven and Generate SOYC Reports

2009-06-25T23:45:04-06:00

One of the most interesting features coming in GWT 2.0 is code splitting and the ability to use GWT.runAsync() to reduce the size of your application's initial download. This week, I learned how to use GWT 2.0 with my GWT 1.6/Maven project. Below are instructions on how to build and use the latest GWT with Maven.

Checkout GWT and setup GWT_TOOLS.
Set a GWT_VERSION environment variable to 2.0.0-SNAPSHOT (export GWT_VERSION=2.0.0-SNAPSHOT).
Build GWT with the ant command.

After building completes, install the GWT artifacts into your local Maven repository using the following commands:

mvn install:install-file -DgroupId=com.google.gwt \
-DartifactId=gwt-user -Dversion=2.0.0-SNAPSHOT \
-Dpackaging=jar -Dfile=build/lib/gwt-user.jar

mvn install:install-file -DgroupId=com.google.gwt \
-DartifactId=gwt-servlet -Dversion=2.0.0-SNAPSHOT \
-Dpackaging=jar -Dfile=build/lib/gwt-servlet.jar

mvn install:install-file -DgroupId=com.google.gwt \
-DartifactId=gwt-dev -Dversion=2.0.0-SNAPSHOT \
-Dclassifier=mac -Dpackaging=jar -Dfile=build/lib/gwt-dev-mac.jar

mkdir temp
tar -zxf build/dist/gwt-mac-2.0.0-SNAPSHOT.tar.gz -C temp
cd temp/gwt-mac-2.0.0-SNAPSHOT
zip -0 gwt-mac-2.0.0-SNAPSHOT.zip lib*.jnilib
cd ../..

mvn install:install-file -DgroupId=com.google.gwt \
-DartifactId=gwt-dev -Dversion=2.0.0-SNAPSHOT \
-Dclassifier=mac-libs -Dpackaging=zip \
-Dfile=temp/gwt-mac-2.0.0-SNAPSHOT/gwt-mac-2.0.0-SNAPSHOT.zip

Thanks to Jason for his help with this script.

Modify the pom.xml of your GWT project to use the the gwt-maven-plugin from Codehaus. Of course, you'll need to modify the <runTarget> to fit your project.

<plugin>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>gwt-maven-plugin</artifactId>
    <version>1.1</version>
    <configuration>
        <runTarget>org.appfuse.gwt.mvc.${entry.point}/${entry.point}.html</runTarget>
    </configuration>
    <executions>
        <execution>
            <goals>
                <goal>compile</goal>
                <goal>test</goal>
            </goals>
        </execution>
    </executions>
</plugin>

Modify your dependencies to match the ones below. With the Codehaus plugin, dependencies are much more concise.

<dependency>
    <groupId>com.google.gwt</groupId>
    <artifactId>gwt-servlet</artifactId>
    <version>${gwt.version}</version>
    <scope>compile</scope>
</dependency>
<dependency>
    <groupId>com.google.gwt</groupId>
    <artifactId>gwt-user</artifactId>
    <version>${gwt.version}</version>
    <scope>provided</scope>
</dependency>

Add <gwt.version>2.0.0-SNAPSHOT</gwt.version> to the properties section of your pom.xml.
At this point, you should be able to compile your project with mvn gwt:compile and run it in hosted mode using mvn gwt:run.

Generate SOYC Reports
In Google's code splitting documentation, it mentions The Story of Your Compile (SOYC). From the documentation:

To obtain a SOYC report for your application, there are two steps necessary. First, add -soyc to the compilation options that are passed to the GWT compiler. This will cause the compiler to emit raw information about the compile to XML files in an -aux directory beside the rest of the compiled output. In that directory, you will see an XML file for each permutation and a manifest.xml file that describes the contents of all the others.

The second step is to convert that raw information into viewable HTML. This is done with the SoycDashboard tool.

The first step is not currently possible with the gwt-maven-plugin, so I created a patch for it.

If you patch the gwt-maven-plugin and install it locally, make sure and change the version in your pom.xml to 1.2-SNAPSHOT.

To use the SoycDashboard tool, you'll need to install the gwt-soyc-vis.jar.

mvn install:install-file -DgroupId=com.google.gwt \
-DartifactId=gwt-soyc-vis -Dversion=2.0.0-SNAPSHOT \
-Dpackaging=jar -Dfile=build/lib/gwt-soyc-vis.jar

Now you can generate SOYC reports with mvn gwt:compile -Dgwt.compiler.soyc=true. You can also add <soyc>true</soyc> to the <configuration> section of the gwt-maven-plugin.

The second step (converting the raw information into viewable HTML) is possible using java from the command-line, or by using the exec-maven-plugin. Here's the (lengthy) command-line version:

java -Xmx1024m -cp /Users/mraible/.m2/repository/com/google/gwt/gwt-soyc/2.0.0-SNAPSHOT/gwt-soyc-2.0.0-SNAPSHOT.jar:/Users/mraible/.m2/repository/com/google/gwt/gwt-dev/2.0.0-SNAPSHOT/gwt-dev-2.0.0-SNAPSHOT-mac.jar com.google.gwt.soyc.SoycDashboard -resources ~/.m2/repository/com/google/gwt/gwt-soyc/2.0.0-SNAPSHOT/gwt-soyc-2.0.0-SNAPSHOT.jar -out target/soyc-report target/extra/org.appfuse.gwt.mvc.MVC/soycReport/stories0.xml.gz target/extra/org.appfuse.gwt.mvc.MVC/soycReport/dependencies0.xml.gz target/extra/org.appfuse.gwt.mvc.MVC/soycReport/splitPoints0.xml.gz

In this example, I'm using the files from stories0.xml.gz, dependencies0.xml.gz, splitPoints0.xml.gz. In the soycReport output directory, there's 5 of each these files and I'm not sure what the difference between reports is. Hopefully someone on the GWT team can elaborate. The exec-maven-plugin version is as follows:

<plugin>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>exec-maven-plugin</artifactId>
    <version>1.1</version>
    <configuration>
        <executable>java</executable>
        <arguments>
            <argument>-cp</argument>
            <argument>
                ${settings.localRepository}/com/google/gwt/gwt-soyc/2.0.0-SNAPSHOT/gwt-soyc-2.0.0-SNAPSHOT.jar:${settings.localRepository}/com/google/gwt/gwt-dev/2.0.0-SNAPSHOT/gwt-dev-2.0.0-SNAPSHOT-${platform}.jar
            </argument>
            <argument>com.google.gwt.soyc.SoycDashboard</argument>
            <argument>-out</argument>
            <argument>target/soyc-report</argument>
            <argument>-resources</argument>
            <argument>
                ${settings.localRepository}/com/google/gwt/gwt-soyc/2.0.0-SNAPSHOT/gwt-soyc-2.0.0-SNAPSHOT.jar
            </argument>
            <argument>${project.build.directory}/extra/org.appfuse.gwt.mvc.MVC/soycReport/stories0.xml.gz</argument>
            <argument>${project.build.directory}/extra/org.appfuse.gwt.mvc.MVC/soycReport/dependencies0.xml.gz</argument>
            <argument>${project.build.directory}/extra/org.appfuse.gwt.mvc.MVC/soycReport/splitPoints0.xml.gz</argument>
        </arguments>
    </configuration>
</plugin>

After configuring this plugin in your project, you should be able to run mvn gwt:compile exec:exec and open the generated report (at target/soyc-report/SoycDashboard-index.html). Currently, there doesn't seem to be much documentation on SOYC. Fred Sauer's recent presentation talks a bit about SOYC and GWT.runAsync(), but that's about it.

To figure out how to use GWT 2.0 with Maven, I used my GWT MVC Example project. The first SOYC report I generated said the initial download was 108,967 KB. To integrate GWT.runAsync(), I modified all the project's controllers so their handleEvent() methods changed from this:

public void handleEvent(AppEvent event) {
    onViewHome(event);
}

To this:

public void handleEvent(final AppEvent event) {
    GWT.runAsync(new RunAsyncCallback() {
        public void onFailure(Throwable throwable) {
            Window.alert(throwable.getMessage());
        }

        public void onSuccess() {
            onViewHome(event);
        }
    });
}

When I generated a new SOYC report, the initial download size was reduced to 56,718 KB. Furthermore, I was able to see that my "Leftovers code" consisted of 63,175 KB. I'm sure there's better ways to split my project using GWT.runAsync(), but I'm happy to see I was able to reduce the initial download by 50%.

If you'd like to try GWT 2.0, you can can download my gwt-mvc example project. To build/run this project, you'll need to 1) build and install GWT, 2) patch gwt-maven-plugin and 3) run mvn gwt:compile exec:exec to generate the SOYC report. In an ideal world, the gwt-maven-plugin can be enhanced to generate the SOYC report (rather than using the exec-maven-plugin). In the meantime, I think it's pretty cool that you can try out GWT 2.0 features while they're still being developed.

Testing GWT Applications

2009-02-09T15:27:36-07:00

Last week, I did some research on GWT, how to test it and code coverage options for tests that extend GWTTestCase. The reason I did this is because I've found that most of the GWT tests I write have to extend GWTTestCase and I'd like to have code coverage reports. Read below for more information on my findings for testing GWT classes.

There are quite a few articles about testing GWT applications. Here are a few samples:

Test-First GWT
Test driven development for GWT UI code
Test driven development for GWT UI code with asynchronous RPC
Enabling Test Driven Development in GWT client code
JUnit tests for widgets - thread about which components to test.

The main gist of these articles is that you should structure your code to make the core functionality of your application testable without having to depend on GWTTestCase.

All of them also advocate using an MVC or MVP (Model View Presenter) pattern. Currently, I'm using GXT and its MVC Framework. Unfortunately, GXT's MVC doesn't have much documentation. The good news is there is a good article that explained enough that I was able to refactor my project to use it.

The unfortunate side of this refactoring was I discovered that classes that extend GXT's MVC Framework have to be tested with GWTTestCase. The downside to extending GWTTestCase is there is it's difficult to create code coverage reports.

GWT's issue 799 has some patches that should make code coverage possible. I tried to implement code coverage with Eclipse and EclEmma using this README, but failed. In the process, I discovered an issue with Eclipse 3.4 and JUnit on OS X. Reverting to Eclipse 3.3 solved this problem, but I was still unable to make EclEmma work with GWT.

After failing with Eclipse, I tried to use the emma-maven-plugin. I was also unable to get this to work, with my findings documented in this thread.

Finally, I did have some luck with getting IDEA's built-in code coverage feature working. However, after getting it to work once, it failed to work for the rest of the day and I haven't had success since.

Code Coverage and GWT
Because of these issues with GWT 1.5 and code coverage, I think I'll wait until GWT 1.6 to worry about it. The good news is 1.6 M1 was released last Friday. If continuing to use GWTTestCase becomes an issue, I may write my own MVC Framework that doesn't use classes that call native JavaScript. Hopefully GXT MVC's framework will provide a good example.

In addition to trying to get code coverage working, I used the internets to figure out how run GWT tests inside of Eclipse and IDEA. I don't remember the resources I used, but hopefully this up-to-date documentation will help others. The nice thing about using an IDE to run these tests is they typically execute much faster.

Running GWT Tests in Eclipse
You should be able to run most of your GWT tests from within Eclipse using the following steps.

Right-click on a test that extends GWTTestCase and go to Run As > JUnit Test. It's likely you will see the error message below.

Invalid launch configuration: -XstartOnFirstThread not specified.

On Mac OS X, GWT requires that the Java virtual machine be invoked with the
-XstartOnFirstThread VM argument.

Example:
  java -XstartOnFirstThread -cp gwt-dev-mac.jar com.google.gwt.dev.GWTShell

To fix this error, go to Run > Open Run Dialog. Click on the Arguments tab and add the following values. The 2nd value is to increase the amount of memory available to the test and avoid an OOM error.
```
-XstartOnFirstThread -Xmx512M
```

When you re-run the test, you will probably see the following error:

com.google.gwt.junit.JUnitFatalLaunchException: The test class 'org.richresume.client.home.HomeControllerGwtTest' 
was not found in module 'org.richresume.client.Application'; no compilation unit for that type was seen
  at com.google.gwt.junit.JUnitShell.checkTestClassInCurrentModule(JUnitShell.java:193)
  at com.google.gwt.junit.JUnitShell.runTestImpl(JUnitShell.java:628)
  at com.google.gwt.junit.JUnitShell.runTest(JUnitShell.java:150)
  at com.google.gwt.junit.client.GWTTestCase.runTest(GWTTestCase.java:219)

To fix this, open the Run Dialog again, click on the Classpath tab and click on User Entries. Click on the Advanced button and select Add Folders. In the Folder Selection dialog, select your source and test directories (e.g. src/main/java and src/test/java).
Run the test again and you should see a green bar in your JUnit tab.
To create a JUnit configuration that runs all tests, duplicate the previously mentioned run configuration. Then change the name to "All Tests" and select the 2nd radio button to run all tests in the project.
Click Run to execute all the tests in the project.

Running GWT Tests in IDEA
You should be able to run your GWT tests from within IDEA using the following steps.

Right-click on a test that extends GWTTestCase and go to Run "TestNameGwtTes...". It's likely you will see the error message below.

Invalid launch configuration: -XstartOnFirstThread not specified.

On Mac OS X, GWT requires that the Java virtual machine be invoked with the
-XstartOnFirstThread VM argument.

Example:
  java -XstartOnFirstThread -cp gwt-dev-mac.jar com.google.gwt.dev.GWTShell

If you get a compiler error instead, you may need to add the GWT Facet to your project. To do this, right-click on your project's top-most folder in the left pane. Select Module Settings > Facets and enable GWT for your module.
To fix the -XstartOnFirstThread issue, go to Run > Edit Configurations. Add the following values to the VM Arguments field. The 2nd value is to increase the amount of memory available to the test and avoid an OOM error.
```
-XstartOnFirstThread -Xmx512M
```
NOTE: If you still get a compiler error, see this page for a possible solution.
Run the test again and you should see a green bar in your Run tab.
To create a JUnit configuration that runs all tests, duplicate the previously mentioned run configuration. Then change the name to "All Tests" and change the Test configuration to search for tests in the whole project.
Run the new configuration to execute all the tests in the project.

Testing GWT applications isn't as straightforward as writing JUnit tests, but I do believe it's getting better. If you have any additional tips and tricks, please let me know.

AppFuse Light » AppFuse, Maven Archetypes and Shared Web Assets

2008-10-29T02:18:59-06:00

Last night, I stayed up into the wee hours of the morning working on something I've been wanting to do for a long time. It wasn't until I was trouncing around the woods in Montana that I realized how easy it would be. The something I've wanted to do was to modify AppFuse Light to use AppFuse's core modules (service and dao). It only took me a few hours to make it happen and it inspired additional ideas.

I believe the major mistake we made in AppFuse 2.x was making it easy for user's to upgrade their applications. We currently use the maven-war-plugin and our own maven-warpath-plugin to make it possible to include AppFuse classes and assets in your project. You can easily start a new project w/o having a whole bunch of files in your project. The problem is, you can't easily use "mvn jetty:run" to work on your project. Of course, you can use "mvn appfuse:full-source" to solve this, but I'm starting to think more and more that "full-source" should be the default. This is what we did in 1.x and it seems to be the more natural pattern for folks using AppFuse.

That hard part about moving to "full-source" by default is coming up with a way to share common assets and classes among wars and war projects. Sure, I can copy all the shared images, css and js into each project - but that could become a maintenance nightmare. Subversion 1.5 with relative svn:externals might solve this, but it still seems kinda hacky. I don't want to use the maven-war-plugin because the overlay is kinda hokey and I think it's easier for users to understand when everything is in their project. AppFuse's current directory structure in SVN looks as follows. I've added indicators of what is in each directory.

Rather than using AppFuse's current (manual) archetype-creation process, I'd like to move to a more automated creation process using the maven-archetype-plugin's create-from-project feature. I'd like to figure out a way where I can have the source code and assets from web/common included in each of the other web/* projects (both when using "jetty:run" and "archetype:create-from-project"). One idea I thought of is to make Jetty/Maven aware of multiple src/war directories for "jetty:run" and "package" and then somehow hook into the archetype plugin at creation time to pull in the shared resources. I don't know if something like this is possible. If you know of a good solution to this shared web assets issue, I'd love to hear about it.

Back to AppFuse Light. If I can figure out how to solve shared resources in web modules, I can use this in AppFuse Light to move to a modular SVN structure vs. its current "use Ant to create different combinations" setup. If a modular structure (like appfuse/web/*) is possible for AppFuse Light, I believe it makes sense to move its source into AppFuse's SVN repository. Below is how the directory structure might look after this move.

With this addition and "archetype:create-from-project", we should be able to create all the basic and light archetypes automatically. We'll probably still need a manual archetype-creation process for modular archetypes, but I'm OK with that.

The last thing I'm struggling with is figuring out the best way to create archetypes for something like AppFuse. In the past, we've used dependencies to allow users to inherit dependencies and their versions. This works, but it results in a lot of duplicate XML (in projects and archetypes) for developers. Last night, I tried using a parent project instead of dependencies and it seems to work much better. Not only do you inherit dependencies, but you also inherit plugins, profiles and properties. If you inherit, you can override, which is slick.

If you're an AppFuse user, how would you feel about having an AppFuse module as your project's parent? Would you prefer that, dependencies on AppFuse or full-source with no dependencies on AppFuse? Regardless of parent vs. dependencies, I think running "appfuse:full-source" should allow you to de-couple your project from AppFuse.

Applying Flash to Java: Flex and OpenLaszlo with Dustin Marx

2008-10-22T14:31:10-06:00

If you're going to choose Flex or OpenLaszlo, chances are you're targeting Flash. The Flash Player allows you to abstract the browser idiosyncrasies and give users a better experience. It hides the browser quirks from both developers and users. It's also a highly ubiquitous web browser runtime environment. It provides a user experience way beyond traditional HTTP request-response. Also, its visual effects and "richness" rival of non-browser desktop applications.

Mark's blog stats show that 95% of readers are using Flash 9 and 1% is Flash 10. All others don't have their version exposed. Most other sources claim that Flash 9 has 98% penetration in mature markets. One of the nicest things about Flash is it frees users from limitations of traditional web applications. Request/response is largely a thing of the past and Ajax-like behavior was built-in from the beginning.

Flash Criticisms: has reduced SEO as well as bookmarking and URL history support.

Flash Player Criticisms: not open source, no significant alternative, no 64-bit player, loading performance and it's only useful for games, movies and annoying advertisements.

The good news is Flash is getting better. There's currently a SWF Searchability initiative with Google and Yahoo!. For bookmarking and URL History, you can use "deep linking" with mx.managers.BrowserManager and mx.managers.HistoryManager. Flash Player issues are also being addressed. There's a Flash Open Screen Project, there's a 64-bit player in Adobe Labs and Flash 9/10 is much better than in the past.

To prove that Flash is a compelling technology, all you have to do is look at Microsoft's Silverlight and Sun's JavaFX. These are direct competitors that are fairly new and prove that companies like what Flash has.

Flex
Flex is not Flash. Flex requires Flash (9+), but Flash does not require Flex. Flex is a language and framework and applications are compiled into .swf files. Flash is the runtime environment that executes .swf files. Flex 3 is FREE. The Flex SDK, compiler and debugger are open source. They have no license costs. BlazeDS is also open source and has no license cost.

Flex MXML was formerly called Macromedia XML. It's an XML-based presentation/layout language that's editable with any text editor or IDE. MXML is to ActionScript 3 as JSP is to Java. MXML provides the layout and ActionScript provides the dynamic business logic.

ActionScript
ActionScript is an ECMAScript implementation that's been proposed as the Edition 4 implementation. It's not your older sibling's JavaScript. It uses class-based object-oriented features and static typing. Thanks to the Flash Player, it works the same across multiple browsers. Most of the things you can do with MXML, you can do with ActionScript. However, MXML typically requires less LOC.

ActionScript allows packages, interfaces, inheritance, objects and methods. It includes extensive XML Support, particularly E4X (ECMAScript for XML). It has a large class library and can talk directly to the Flash Player. Finally, it has many Java-like features and it's syntax looks similar.

At this point, Dustin started doing demos of two popular Flex components: RichText Editor (which creates horrible HTML) and Data Grid. More third-party Flex components seem to appear every day. Examples include flexlib, ASDIA as well as all those listed on FlexBox. Additionally, it's not too difficult to create your own Flex components (no proof provided).

Flex's property binding is one of Dustin's favorite features, but he says he has a difficult time conveying how cool it is. Property binding allows you to tie data in one object to data in another object. Updates in one object affect another. To use it in MXML, you can use curly braces or the tag. In ActionScript, you can use the BindingUtils object. You can also use Flex's metadata annotation "Bindable" to denote bindable objects.

To compile Flex applications, you can use mxmlc from the command line. You can use Ant with the <exec> task or using Flex's Ant Tasks. You can also invoke mxmlc from Java as long as you include mxmlc.jar in your classpath. FlexBuilder is an Eclipse-based IDE that's not included with the free Flex SDK. It's not a free product and can be used as a plugin or a standalone IDE.

Flex and Java
There's two predominant out-of-the-box methods for Flex to communicate with Java EE backends.

HttpService: traditional HTTP request/response.
WebService: SOAP-based Web Services.

If the above two methods aren't fast enough, you can use BlaseDS and it's additional options.

Web Messaging: HTTP publish/subscribe with JMS, ColdFusion and/or other Flash/Ajax client.
Remoting with AMF: access server-side objects from Flash client-tier as if they were hosted there.

Flash applications can access either a client's machine or a remote site, but not both. You can use a crossdomain.xml file on your server to allow remote Flash clients to connect. This file allows access for both Flex and OpenLaszlo applications.

BlazeDS adds proxy server support for HTTPService and WebService. To use, set the useProxy attribute to "true". Features include authentication and logging. It adds a new RPC mechanisms called RemoteObject. This object allows ActionScript and Java EE transparent integration. It also adds publish/subscribe messaging with a JMS Adapter available. Lastly, it adds Ajax support to your Flex application.

GraniteDS is an open-source (LGPL) alternative to Adobe LiveCycle and is similar to BlazeDS. It has COMET-like functionality and supports Spring, Spring Security, EJB 3, Seam and Guice.

Flex Frameworks: Cairngorm (Adobe Consulting), Pure MVC, Mate and many others.

Flex 4 (Gumbo) will have improvements for designers (easier customization, better tool support), improvements for developers (faster compiler, two-way data binding) and will leverage new features of Flash 10.

OpenLazlo
OpenLaszlo 4 is XML-based and uses an XPath syntax for data access. OpenLaszlo was actually created before Flex and is ECMAScript-based. Unlike Flex that requires Flash 9, OpenLaszlo is architected to deploy on different runtime environments, including: Flash 7/8/9 and DHTML. Dustin believes OpenLaszlo would be a lot more appealing if your source code could be compiled into Silverlight or JavaFX.

OpenLaszlo's syntax looks a lot like Flex, except it does not use namespaces. OpenLaszlo's Constraints are similar to Flex's property binding, except the syntax is a bit different. You use ${} in LZX tags or applyConstraint() and LzDelegate in scripts. OpenLaszlo's event handling is similar to Flex and JavaScript event handling. All attributes have an implicit "on" event that is triggered when an attribute's value is changed. Event handlers can be written CSS-style in LZX nodes or using the <handler></handler> tag. Script code can be embedded in LZX XML in many ways:

Inside event attributes
Within <script></script> tags
Within <method></method> tags
Within <handler></handler> tags
In a separate file (<script src="someFile.js" />)

Dustin believes the debugger and view-source tools in OpenLaszlo are much better than the ones available for Flex.

For the rest of the presentation, Dustin covered many of Laszlo's feature, how they relate to Java as well as how to integrate SWF and HTML. SWFObject is Dustin's preferred method for adding Flash to HTML. One of its nifty features is it allows SWF-to-SWF communication.

This talk was an excellent and in-depth overview of Flash, Flex and OpenLaszlo. I especially liked all the details on ActionScript and the different methods for remote communication. Nice job Dustin!

Comprehensive Project Intelligence with Jason van Zyl

2008-10-21T14:35:13-06:00

In this talk, Jason is going to talk about m2eclipse, Nexus, Hudson and Maven. On his Maven bullet-point, it says "The best is yet to come (and we'll fix a bunch of stuff)!"

m2eclipse
The m2eclipse plugin has improved greatly in the last 4 months - there's now 5 full-time developers working on it. If you use the m2eclipse plugin, you never have to leave the IDE for your Maven-related work. m2eclipse has a Configuration Framework that turns Maven's mumbo-jumbo (Jason's words, not mine) into Eclipse talk. The m2eclipse+configuration framework has integration for WTP, JDT, AJDT and they're working on one for Flex. Below is a screenshot of how m2eclipse helps developers stay away from using command-line Maven.

Now Jason is showing a demo of m2eclipse and creating a new Maven project from existing archetypes. It looks like m2eclipse uses "Nexus Indexer" as its Catalog. Presumably this is a Sonatype-hosted service. The Nexus Indexer contains an of Maven Central and is very fast. It's dynamically updated as new things are deployed to Maven Central.

If you use m2eclipse and open a pom.xml, you'll get a visual view rather than an XML view. This UI has tabs for Overview, Dependencies, Repositories, Build, Plugins, Reporting, Profiles, Team, a Dependency Hierarchy and Dependency Graph. You can easily add new dependencies and it finds things quickly because it's using the Nexus index. In addition to visually adding dependencies, you can modify the raw XML and get things like groupId and version code-completion.

Once you have your dependencies listed in a "Maven Dependencies" container to you can "Materialize Project" to create a project from the binary dependency. You'll get the source as a new project in your workspace as well as having your binary dependency turned into a source dependency.

You can easily create a run configuration that runs certain goals, allows you to activate profiles and uses an embedded version of Maven or an external installation. I asked Jason if the Dependency Hierarchy had a right-click -> exclude feature and he said it doesn't exist yet, but it will in the release after next. For now, the pom editor is just eye candy and doesn't have actions.

For Maven Plugins, m2eclipse has workspace resolution so you can develop a plugin and use it in a project at the same time w/o having to install the plugin over and over.

Sonatype has created a Project Materializer Plugin that allows a team lead to create a project for developers. It allows you to create a welcome page that has links, cheat sheets, News and Updates and Tasks for the developer. It also materializes Eclipse projects in the background. Cheat Sheets are a series of tasks that can be run to show developers how to do things.

Another big feature in m2eclipse is nested project support. It only works in Eclipse 3.4 though.

Nexus
Nexus is a repository manager that allows you to keep the cruft from the outside world out of your system. It's primarily for Repository and Configuration Management. It has fine-grained security for authentication and authorization. One nice feature of its security system is you can prevent certain users from seeing source JARs. It also has virtual repositories (a savior for OSGi lovers). UI is written in Ext JS and acts as a simple REST client for Nexus. It has a full REST API using RESTlet.

A repository manager allows you to protect yourself from the Open Source Ghetto. The OS Maven Ghetto has bad POMs, repositories in POMs, mixed snapshot and release dependencies and screwed up metadata. Not only does it offer protection, but it allows you to aggregate repositories and publish your internal artifacts to it. It also allows you to schedule tasks that clean out snapshots so your repositories don't grow out of control.

Typically people deal with OSGi runtimes manually. OSGi can dynamically update dependencies that you drop into your bundle repository. However, many folks maintain their OSGi runtime and bundle repository locally. Some people are trying to get an OSGi runtime to resolve against a P2 repository. P2 is what Eclipse uses for their repository management. Nexus has the ability to lock down the versions that are available to an OSGi runtime. Furthermore, you can use Nexus to manage the versions that get deployed to all your servers. This makes it a lot easier for QA and Production to manage versions of your artifacts. OSGi is great for modularity and solving classpath issues, but it does have issues with versions and how its ranges work.

You can see Nexus in action at http://repository.sonatype.org. It can be configured entirely through the UI, an XML file or through the REST API. RSS feeds exist for configuration and repository updates.

Nexus is free and open source with a GPL license. The next version (1.2) will contain a Plugin API to allow extensions. All of Sonatype's enhancements for its commercial version will be written as plugins. A matrix of what's available in the open source version vs. commercial version should be published sometime next week.

Hudson
Jason believes that Hudson is the future of continuous integration, on-demand results and release management. They're writing all their extension points in Hudson as Maven plugins and Plexus components (with the work they've done, using Spring components should also be possible). Other enhancements they've made to Hudson:

Integration of JSecurity
Implementing a similar REST layer as Nexus and creating a UI using Ext JS
Automatic installation of external Maven installations
Drools Workflow Integration

They've also enhanced Hudson so it can easily test/publish Maven projects without using the free-form project template. Hudson works well for doing Eclipse headless builds for Eclipse plugins. If you need to test against multiple databases, multiple OS's, it does support a grid-based system that's easy to setup. Hudson does have web services integration that allows you to kick off builds from within Eclipse. Sonatype uses Hudson to run all their nightly builds of Maven.

Maven - the best is yet to come
The three big things coming in the next version of Maven are:

Refactored Project Builder: includes a spec for building a pom, domain-specific parsers (attribute-based XML, Groovy and Ruby) and mixins.
Mercury: a new repository and transport layer. Developed by the Jetty people and is super fast (async client with connection pooling and parallelization). Has atomic downloads and deployments (with Nexus), full PGP support and a WebDAV client built-in.
Maven Embedder: re-written to actually work.

Overall, a good talk with lots of demos. I'm definitely looking forward to Maven improvements in the future.

Integrating Compass 2.0 into AppFuse

2008-05-22T21:24:47-06:00

Last week, Chris Barham showed us an example of how to implement external sorting and paging with AppFuse + DisplayTag. This week, he's at it again with a tutorial titled Searching in AppFuse 2.0.2 with Compass 2.0 and Lucene 2.3.2.

From a message he sent to the mailing list:

I've extended the previous DisplayTag external sorting and paging project to implement full search capability across the domain objects by using Compass 2.0 - http://www.compass-project.org.

Although there are a number of tutorials around for Compass and AppFuse, I thought I'd update as Compass has just gone to version 2.0 and has new features, (annotations etc).

Search results in the example are displayed in plain HTML with Compass' own paging feature, and also using DisplayTag with its paging external feature, (both on the same search results page in the example).

Code is in a branch off the original project called branches/search - check it out with:

svn checkout http://pagingappfuse.googlecode.com/svn/branches/search/ appfusecompass

Instructions on how to implement Compass are here:
http://code.google.com/p/pagingappfuse/wiki/CompassSearching

Cheers,
Chris

Again, great work Chris! We really appreciate your contributions.

Issues with AntRun Plugin and Maven

2008-05-10T18:23:26-06:00

I started seeing the following error today when using Maven and the AntRun Plugin.

[INFO] [antrun:run {execution: default}]
[INFO] Executing tasks
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Error executing ant tasks
	
Embedded error: java.lang.IllegalAccessError: tried to access method 
org.apache.tools.ant.launch.Locator.decodeUri(Ljava/lang/String;)Ljava/lang/String; 
from class org.apache.tools.ant.AntClassLoader

Searching the internet provided no results, so I was pretty stumped - especially since this error didn't happen on my MacBook Pro. It happened on AppFuse's Bamboo server (Linux), but not locally. Luckily, I was able to reproduce it on my Windows box and discovered the solution: upgrade to a newer version of Maven. I was using 2.0.6/2.0.7 and upgrading to 2.0.9 fixed the problem.

BTW, when is the Ant project going to release a new version of Ant? The current 1.7.0 version doesn't support spaces in path names, which seems like a pretty big issue to me (especially for Windows users).

Upgrading to Spring Security 2.0

2008-04-17T02:45:47-06:00

This evening I spent a few hours and upgraded AppFuse to use Acegi Spring Security 2.0. The upgrade was fairly straightforward:

%s/org.acegisecurity/org.springframework.security/g

Upgraded dependencies (exclusions are necessary if you're using Spring 2.5.x and don't want 2.0.x dependencies pulled in):

<dependency>
    <groupId>org.springframework.security</groupId>
    <artifactId>spring-security-core-tiger</artifactId>
    <version>${spring.security.version}</version>
    <exclusions>
        <exclusion>
            <groupId>org.springframework</groupId>
            <artifactId>spring-core</artifactId>
        </exclusion>
        <exclusion>
            <groupId>org.springframework</groupId>
            <artifactId>spring-support</artifactId>
        </exclusion>
    </exclusions>
</dependency>
...
<dependency>
    <groupId>org.springframework.security</groupId>
    <artifactId>spring-security-taglibs</artifactId>
    <version>${spring.security.version}</version>
    <exclusions>
        <exclusion>
            <groupId>org.springframework</groupId>
            <artifactId>spring-web</artifactId>
        </exclusion>
    </exclusions>
</dependency>

Changed taglib prefix from "authz" to "security" and change the associated taglib declaration to:
```
<%@ taglib uri="http://www.springframework.org/security/tags" 
    prefix="security" %>
```
In web.xml, I changed <filter-class> to org.springframework.web.filter.DelegatingFilterProxy. Since I didn't name my filter springSecurityFilterChain, I also had to add the following <init-param>:
```
    <init-param>
        <param-name>targetBeanName</param-name>
        <param-value>springSecurityFilterChain</param-value>
    </init-param>
```
Lastly, I modified security.xml to use the new syntax. AppFuse's security.xml went from 175 lines to 33 with the new security namespace configuration!

It's hard to believe I first looked at Acegi almost 4 years ago. At that time, I said it contained too much XML for my needs. Ben's reaction:

Seriously, the "whole lotta XML" gives you exponentially more power and flexibility than a method such as this could ever hope to provide you.

It's nice to see that Spring Security 2.0 gives you exponentially more power and flexibility without all the XML. Thanks guys!

P.S. You can also view the full changelog for this upgrade.

Update: If you're using <authz:authentication property="fullName"/> in your JSPs, you'll need to change it to <security:authentication property="principal.fullName"/>.

Maven Integration for Eclipse

2008-03-12T16:22:43-06:00

If you're a Maven user and like Eclipse, you might want to checkout the new Maven Integration Plugin for Eclipse 0.9.0. Euxx has a couple blog posts talking about the new features - looks like pretty cool stuff to me.

Indexing Maven repositories - for offline browsing of repositories.
Making a good use of Maven metadata - materializing projects from dependencies.

The second feature is especially cool. If your dependencies supply SCM information - you can import the project from its source control system. Maven may have warts, but it also has incredible potential.

Building a Better Maven with Ant

2008-02-11T14:07:12-07:00

It looks like the Ant folks are thinking of building a better Maven.

I see many developers adopt Maven because they want a build system able to provide common features with no effort. Most of them don't want to spend much time writing an Ant script, or have seen or heard that maintaining Ant build scripts is troublesome. So they choose to use Maven only because it's easy to use for common use cases: install, write a simple pom of a few lines or generate it using an archetype, and you're ready to compile, test and package your new project following the Maven standard structure. They also get dependency management for free, and with only a few more effort they have multi module builds, and some nice features like code analysis, coverage, and a set of report gathered in a web site. That's really nice and that's what I like about Maven.

But Maven suffers from a lack of flexibility and robustness IMHO. And later the same people who first adopted Maven because of its perceived ease of use become frustrated when they need to tweek the system to their own needs or don't understand how the release plugin work. Then some of them go back to Ant, first having to go through a sometimes painful road to describe their whole build system in xml, especially if they aren't Ant experts. Others try to use new build tools like raven, buildr or others.

I really like Ant, and think it is a very good basis for robust and flexible build systems. People with enough knowledge of Ant can write very good build systems, testable, maintainable and adaptable. But you need to get your hands dirty, and you need to get a good knowledge of some of the mechanisms which can make an Ant based build system manageable: import, scripts and scriptdef, macrodef, presetdef, and so on. [Read More]

What do you think - is this a good idea?

I agree that Maven has its warts, but I don't think it's that bad. I've also heard that Maven has been successfully implemented at large companyies like eBay, Intuit and E*Trade[1]. Is the "Maven sucks" meme largely something that exists in the blogosphere, but not in the real world?

I think the biggest benefit of Maven is dependency management. I think it makes your code more modular and easier to build. Rather than having a monolithic source-code tree that depends on itself being built in a certain order, you can have individual modules that pull dependencies from a central location. This can be done with Maven's Ant Tasks as well. I don't see a problem with building a better Maven with Ant, but to try and build a better Central Repository sounds like a nightmare to me. The current repository has been improved for years and is much better than it was a couple years ago. That being said, I would love to see somebody build a more accurate Central Repository. Ideally, it'd be done sometime next week.

[1] I could be wrong about these companies. If you're a developer at one of these companies, please confirm or deny. Any comments on Maven's success at these companies would be great as well.

Update: Speaking of Maven, there's an interesting comment on a Javalobby post I wrote:

With all the critical remarks the Maven project is receiving, wouldn't it be time for some Maven project lead to step up and explain the team's position? Or is it completely deaf to the sentiments? How many builds have to fail, how much more headaches are needed before others start their own version of Maven and do it the right way (like Don [Brown])?

Seems like an excellent question to me. Guys?

Reviews: Getting Started with Grails, Rails for Java Developers and Groovy Recipes

2008-02-09T11:34:57-07:00

Two weeks ago, I mentioned a number of books I was hoping to read to get up to speed on Rails and Grails quickly. Over the last two weeks, I was able to polish off three of these (listed in order of reading):

Below are short reviews of each book.

Getting Started with Grails
The Good: This is the perfect book to learn the basics of Grails quickly. At 133 pages, I was able to read this entire book in one sitting. The first couple chapters are very introductory, but likely necessary for beginners. The good news is you start writing your first Grails application on page 7 (Chapter 3).

Chapter 4 (Improving the User Experience) is good in that it shows you how to do warning, error and confirmation messages. This is something often overlooked in web frameworks and Rails and its "flash" concept seem to have made it important again. I remember way back in 2003 when I complained about frameworks not allowing messages to live through a redirect - everyone said it was something you didn't need. Now it's a standard part of most web frameworks.

The Bad: Uses Grails 0.3.1. This is understandable since the book was written in 2006 and published in 2007. Also, it doesn't cover testing that much (5 pages). If testing is so easy with Groovy and if Grails has Canoo WebTest support built-in, it should be shown IMO.

Rails for Java Developers
The Good: This was an interesting book for me because it uses AppFuse for many of its Java-based examples. Unfortunately, it uses the Struts 1.x version which is cumbersome and verbose as far as Java web frameworks go. The most impressive part of this book is how Justin and Stu do an excellent job of walking the line and not insulting Java nor developers using it. They provide an easy to understand view of Rails from a Java Developer's perspective. There's detailed chapters on ActiveRecord (as it compares to Hibernate), ActiveController (compared to Struts) and ActiveView (compared to JSP). This book has excellent chapters on Testing, Automating the Development Process and Security.

The Bad: This book was published over a year ago, so it uses an older version of Rails. This means some commands don't work if you're using Rails 2.0. It's also a little light on Ruby, so I didn't feel I learned as much about the language as I was hoping to. That's understandable as it's more of a Rails book than a Ruby book.

Groovy Recipes (Beta from Jan 3, 2008)
The Good: I really like the style of this book and that it shows you how to get things done quickly with code samples. It's very no-nonsense in the fact that it contains a lot of code and howtos. I really like Scott's writing style and found this book the easiest to read of the three. This may have something to do with my eagerness to learn Groovy more than anything. The most refreshing part about this book is how up-to-date it is. Because it's a Beta, it seems to contain the most up-to-date information on Groovy and Grails. After reading Getting Started with Grails and working with it for a couple weeks, the first Grails chapter seemed a little basic - but that's likely because I've figured out how to mix all those recipes already. The Grails and Web Services chapter definitely has some interesting content, but I've rarely had a need to implement these recipes in a real-world environment. I'd rather see recipes on testing the UI (with the WebTest plugin) and how to use GWT and Flex with Grails. If SOUIs are the way of the feature, this is a must.

The Bad: Not much information on testing with GroovyTestCase, mock objects or implementing Security. If one of Groovy's sweet spots is testing, why isn't there more coverage on this topic? The Java and Groovy integration chapter is especially good, but there's very limited information on Ant and Maven. It's likely the websites provide sufficient documentation, but the Maven section only fills 5 lines on an otherwise blank page. The biggest problem I have with this book is I really like the recipes writing style and would love to see more tips and tricks. At 250 pages, I was able to finish this book with pleasure in a few days.

What's Next?
Now I'm reading JRuby on Rails (Apress) and Programming Groovy (Pragmatic Programmers). Following that, I'll be perusing dead-tree versions of Struts 2 Web 2.0 Projects (Apress), Prototype and script.aculo.us (Pragmatics) and Laszlo in Action (Manning). If any publishers want to send me books on GWT and Flex, I'd be happy to add them to my list.

All Java web frameworks should support hot deploy of a single class

2008-01-24T15:11:18-07:00

In Anyone else using Groovy?, Tim Fennell (inventor of Stripes) raves at how much he likes Groovy now that it supports Java 5 features. He writes that Groovy might offer a solution to make development with Stripes faster:

The other thing I've been wondering about is that if there were enough demand for it we could try adding "improved" groovy support. E.g. throw your groovy actions under WEB-INF and we'll use groovy's built in stuff to do auto-reloading etc.

Gregg Bolinger responds with an excellent idea:

It would be really cool if Stripes could automatically discover and load changes to action beans (including new ones) without the entire app restarting, regardless of what the action bean is written in. But I realize that is a pretty tall order. :)

I agree that it might be a tall order, but I don't think it's impossible. In fact, I think all Java-based web frameworks should support hot deploy of a single class. We shouldn't have to buy JavaRebel to do this. It should be mandatory.

When an application reaches a certain size, the startup time can get pretty lengthy. This is lost development time. Furthermore, if any part of the development cycle takes longer than 15 seconds, there's a good chance developers will do something else (check their e-mail, move onto another task, etc.). Multi-tasking may be a good skill to have, but it's a horrible way to be productive.

Of the frameworks I'm familiar with, only Tapestry 5 and Seam support reloading single classes without restarting the whole application. Why can't the other frameworks "borrow" Tapestry 5's code? Maybe someone should just buy ZeroTurnaround and give away JavaRebel for free.

If I had one wish for 2008, it would be for all Java web frameworks to support this feature. Pretty Please?

Denver Tech Meetup, Consulting Panel and My Jobs Timeline

2008-01-24T13:39:38-07:00

If you live in Denver and are involved in open source (or simply technology in general), you should make it a point to attend tonight's Denver Tech Meetup. I'm planning on going for about an hour. From there, I'm heading over to the DeRailed User Group for a Consulting Panel at 8. If you're interested in moving from a full-time position to contracting, you should come. This is open to the public, so anyone can attend.

While I was thinking about things to talk about on the panel tonight, I started reflecting on the jobs I've had in my almost-11-year career in technology. Here's my timeline since college:

1997: Full-time at MCI Systemhouse
1998: Contractor for IBM Global Services (6 figures w/in 6 months of graduating!)
April 1999 - April 2001: Full-time for eDeploy.com (Friday lunches rocked)
May 2001 - October 2001: Contractor for Douglas County (introduced to Ant, Struts, etc.)
January 2002 - November 2002: Contractor for OnPoint Digital (100% remote)
December 2002 - August 2003: Contractor for Comcast Media Center
August 2003 - October 2003: Contractor for ResortQuest
November 2003 - June 2004: Contractor for Adams County
June 2004 - August 2004: Contractor for Open Logic
October 2004 - December 2004: Contractor for Oak Grove Systems
January 2005 - May 2005: Contractor for Xcel Energy
June 2005 - January 2007: Contractor for Virtuas
February 2007 - June 2007: Contractor for Checkerboard
July 2007 - Present: Contractor for LinkedIn

Phew - that's 14 jobs in 11-ish years! Notice that I've only ever had 2 full-time positions. So far, I have no regrets and really enjoy being a consultant. If you're interested in learning more about how I started Raible Designs or how I get contracts, you might want to read the following posts.

How I started Raible Designs (Nov 2002)
How do you become an independent consultant and get contracts? (Jan 2005)

If you live in Denver and want to learn more - show up at the The Hive at 8:00 tonight.

Update June 2008: My 3rd full-time gig started in May. Now I'm the Lead UI Architect at LinkedIn.

Migrating a Rails app to Grails

2008-01-22T09:37:49-07:00

There's an interesting trend I've seen happening at companies over the last year. More and more, they're experimenting with Rails and/or Grails for both prototyping and real applications. I think this is an excellent use for these frameworks as they both are very productive. The reasons for their productivity is simple: zero turnaround and less code.

For a Java-based company that's built their bread and butter applications on Java and been successful with it, both frameworks can be disruptive. Bread and butter applications tend to be large and somewhat difficult to maintain. In my experience, the biggest maintenance headache is not writing code or fixing bugs, it's the turnaround time required to make changes, run tests and build the application to test in your browser. Since Rails and Grails eliminate the turnaround, it's only natural for developers at companies with a lengthy build process to love their increased productivity.

Over the next couple weeks, I'm going to do some experimenting with porting a Rails application to Grails. Why? Because I think companies are going to have a difficult time choosing between these two frameworks for rapid prototyping and (possible) production deployments. While both frameworks are great for prototyping, the last thing most developers want to do is throw away the prototype and develop it with something else. They want to continue to enhance the prototype and eventually put it into production. With Rails and Grails (and many others), it's possible to build the real application in a matter of weeks, so why shouldn't it be put into production?

For most Java-based companies, putting a Rails application into production is unfamiliar territory. However, a Grails application is just a WAR, so they can continue to use all the Java infrastructure they know and love. So for companies with an established, tuned and successful JVM infrastructure, does it really make sense to use Rails over Grails? The only thing I can think of is language reasons - there's a lot of Ruby fanatics out there.

So again, the purpose of my experiment is simple: to see if a Grails app can do everything a Rails app can. As for language features and scalability, I'm not really concerned with that right now. I'm not looking to prove that either framework should be used for all web applications - just certain types.

Has anyone out there ported a Rails application to Grails? If so, are there any gotchas I should watch out for?

NOTE: I realize that Rails can be deployed on the JVM with JRuby. However, I think many companies have existing Java-based tools (logging, JMX, Spring backends, etc.) that more easily integrate with Grails than Rails. I could be wrong.

RE: Why Grails doesn't use Maven

2008-01-16T10:49:35-07:00

Graeme Rocher's in Why Grails doesn't use Maven:

In his post entitled "Grails - The Good, The Bad and the Ugly", Jonas has some nice praise for Grails, his main beef is that it is not built on Maven.

So I wanted to clarify why exactly we chose not use Maven (by default) and the explanation is there for all to see in Jonas' first example of creating a Grails application vs creating a Maven project:

Instead of
grails create-app name
could be just
mvn archetype:create -U\ -DarchetypeGroupId=net.liftweb\ -DarchetypeArtifactId=lift-archetype-blank\ -DarchetypeVersion=0.4\ -DremoteRepositories=http://scala-tools.org/repo-releases\ -DgroupId=your.proj.gid -DartifactId=your-proj-idMy goodness, what a mouthful the Maven example is. There is a common acronym in the open source world called RTFM (read the *ing manual), when a user asks a question on a mailing list and the "experts" respond by pointing them to the place in the manual.

I think Maven's biggest problems are 1) poor metadata in the central repository and 2) the source of metadata in projects (pom.xml).

I believe #1 can be fixed if the Maven guys allow dependencies to be fixed based on user feedback. It's also gotten a lot better in recent years. In reality, maintaining transitive dependencies is hard and I believe Maven has done a good job. In reality, they're the only ones that slurp up transitive dependencies, so the only other option is to maintain the dependencies yourself.

To fix #2, I think the problem is mainly XML and the verboseness of the elements-only pom.xml that Maven requires. Most of the contents of a pom.xml are either dependencies, plugins or exclusions/variances of Maven's conventions. What if Maven's metadata was pluggable? What if XML was only one option? What if you could write a pom.groovy and describe your entire build process in 5 lines instead of 500? That would be very cool.

I'm still a Maven fan, mostly because it's greatly simplified the maintenance of and releasing of AppFuse. When I do GWT, Seam or Grails development in the future, you can be sure I'll try to use Maven to do the development. Why? Because I've learned how to use it and I don't feel the pain that so many others talk about. I also think it really shines on really large projects (builds that produce 30+ WARs for example). An Ant-based system on really large projects can become quite burdensome and difficult to maintain. Not only that, but it's very difficult to maintain a modular build system (where you can build/test/deploy a single WAR) with Ant. In my experience, really large Ant-based systems take forever to process that everything is up-to-date whereas Maven systems depend on each other and require you to keep them up to date. Sure it requires you to be smarter and run "mvn install" on your subprojects, but I'd rather do that than wait 5 minutes for Ant to process everything just to run a test.

You might remember that the main reason I used to prefer Ant over Maven was speed. That was in Maven 1 days. With Maven 2, speed is no longer a problem and I've found it much easier to run "mvn jetty:run" than "ant deploy" and wait for Tomcat to restart. IMO, the perfect development environment is one were you can run a command-line command (or use your IDE to start the server) and code away without worrying about restarts. Seam and Grails offer this environment, but it's unlikely your entire organization is going to use standardize on those frameworks and not have anything else. I think Maven and the Maven Jetty Plugin offer a nice alternative for the rest of those applications.

REST and Seam Talks at Denver's JUG

2008-01-09T20:59:45-07:00

After a long hiatus, I decided to attend the Denver JUG meeting this evening. Tonight there's a couple of interesting talks:

Give It a REST by Brian Sletten
Seam by Norman Richards

I'll do my best to live-blog these sessions, so hopefully you can read along and learn everything I do.

Give It a REST by Brian Sletten
This talk isn't an implementation talk, it's more of a motivational talk. Brian is trying to answer the question "Why do we care?". We care because we have a lot of WS-Dissatisfaction. "Conventional" Web Services are often:

too difficult for non-trivial tasks (real complexity)
too complex for trivial tasks (artificial complexity)

RPC-based Web Services are mythically interoperable and time/process coupled in painful ways. SOAP has largely become popular because of marketing dollars behind in. REST is more like the "hippy" way that has grass-roots support with no corporate sponsor.

What makes SOAP difficult? It's remote procedure calls and its tunneled using existing application protocols (HTTP). Furthermore, there are no nouns (mappings to business terms), only handlers. There are no semantics, only handlers. When you tie yourself to a contract/WSDL, you can have anything back that you want - so as long as its simple XML. This isn't entirely true because a lot of things can be shoved into XML (Word documents that are Base64 encoded).

The main problem with SOAP is it solves a problem that most people don't have. It solves an edge case, rather than the main problem.

Many people say "SOAP is secure and REST isn't".

Why do people believe this? It's because of the long list of SOAP-related security acronyms: XML Encryption, XML Signature, XKMS, SAML, XACML, WS-Security, WS-Trust, XrML. Even if you're using these in your system, there's no proof that your implementation is secure. REST is what we all use on the web with online shopping, etc. We don't seem to have a problem with the security we use everyday on the web, do we?

SAO is an architectural style promoting loose coupling among software participants. Sompanies have rigid definitions of what constitutes a SOA. Many believe that SOAP is an essential piece, but it's not. SOAP 1.2 and Doc Lit are improvements, but are they necessary? Interestingly, 85% of Amazon's users chose REST over SOAP when given the choice.

What is REST? The acronym stands for REpresentational State Transfer. It's an architectural style based on certain constraints designed to elicit properties of scalability and extensibility. It's an idealized notion of how the early web should work and helped drive the way it eventually did work. It's more than just URLs!

Resource-Oriented Computing focuses on information spaces, not code or objects. It focuses on logical connections and reduces complexity by separating actions from nouns. In the history of the web, we started with URLs that pointed to documents. Eventually, these documents became dynamic and were generated on-the-fly.

URLs are locations on the web that are horrible names because they change so much. URIs are good names that have no way of being resolved. Fundamentally, REST is a separation of the parts of the system: Nouns, Verbs and Representation. A Resource (in a REST architecture) can be a file, a service or a concept. It can also have different representations. Resources are named with Resource Identifiers. It's simply the means of naming a resource. It's a standard syntax that allows various schemes. Often known as URIs (or IRIs). It's orthogonal to satisfying the reference and it's one of the missing pieces of "normal" web services.

Examples of Representation include 1) a particular dereferencing of a Resource Identifier to a Resource at a particular time, 2) a byte-stream tagged with metadata or 3) it could change based on request or processing/display capabilities of the client (Firefox vs. WAP).

REST's verbs are design decisions to minimize the the complexity of implementing a system. GET retrieves a resource and always returns the exact same result. It doesn't change anything in the backend system. Because of this, it allows for easier layering of your system - particularly when you introduce caching for GETs. POST is used to create (or update) a Resource. It does not require a "known URI" and it supports the append operation. PUT creates (or updates) a Resource, but requires a "known URI" and also supports an overwrite operation. Lastly, there is DELETE, which removes a Resource. This is not supported in modern browsers. Just because browsers don't support them doesn't mean you can't implement them in your applications.

REST's concepts were developed by Roy Fielding in his thesis. He was trying to create a system that had the following architectural properties: performance, scalability, generality, simplicity and modifiability. REST allows us to create true client-server applications. To satisfy scalability requirements, REST is stateless. All parameters travel with the request and no session information is maintained on the server. This improves scalability through load-balancing and allows visibility of intermediary processors.

One of the first things that becomes a bottleneck in enterprise systems is the database. This works fine if you like paying Oracle. By using REST and HTTP concepts, it's easy to take advantage of a cache. This allows replication of an external data set where it's too large to copy locally. REST allows you to create Layered Systems that allow you to have managed dependencies between layers. Having a RESTful architecture allows you to swap out the backend without changing the front-end and vise-versa.

Now Brian is going to do some demos using NetKernel. He recommends using HTML documents to describe services. The beauty of developing a RESTful system is there's nothing preventing you from appending ?wsdl to your URLs to return SOAP.

Invoking functionality using web-friendly techniques is a very nice way to build web applications.

What is controversial in REST? When you are not dereferencing you should not look at the contents of the URI string to gain other information.. However, if you structure your URLs in your application in a hierarchical manner, people will be able to use URIs in this way.

What isn't controversial? No one believes you should rely on sessions or other state at the application level. They also believe using nouns, not verbs is an excellent idea.

Seam by Norman Richards
Seam isn't just a web framework, it's an integration technology for building applications for the web. It's a technology that takes your persistence and web technologies and unifies them so you have a simpler view of your system.

First of all, what is Seam?

It's a unified component and event model - you access all your components the same way
It has a declarative state with a rich context model
It provides deep integration with minimal glue code
It minimizes configuration, prefers annotations to XML
It allows a freedom of architectures and technologies
It also allows testing of components in context

With Seam, you have a number of technology choices to make. The first is which business component model you want to use (EJB 3 vs. POJO). You might choose EJB 3 if you want more clustering capabilities. For persistence, you can use Hibernate or any JPA implementation. Norman recommends using JPA if possible. You also have a choice of languages: Java or Groovy (and possibly Scala in the future). Seam gives you a choice of web frameworks. All the examples today will use JSF, but there's also support for GWT and 2.1 will have support for Wicket. Also, there's some non-committers developing support for Flex. Norman believes component-based web frameworks are the best way to develop web applications. While I hear this from a lot of folks component-based framework authors, it seems ironic that the "best" way to develop webapps is not the most popular way (PHP, Struts, Rails).

I think it's ironic that there's a REST (no state) and a Seam (it's all about state) talk in the same night. I'm tempted to ask why a stateful architecture is better than a REST one, but I'm not really that interested in the answer. I think your architecture should be determined by the needs of your application, rather than choosing the architecture and then implementing an application with it.

In addition to choices, Seam gives you a number of tools: CRUD generation, Eclipse and NetBeans support and full IDE support in JBoss Tools / JBoss Developer Studio.

Now Norman is doing a demo - starting by creating a new Seam Web Project in Eclipse. He mentions that he's skipped a number of steps: downloading and installing Seam, downloading and installing JBoss and configuring your Seam installation and database in Eclipse. He has two projects in Eclipse - apparently the New Project wizard creates two - one for the application and one for testing. It's strange that the tests don't go in the actual project. The directory structure has src/action and src/model for your Seam components. After doing some simple CRUD, Norman starts JBoss and looks at the master/detail screens it generates.

To make a Java class a Seam component, you usually only have to add a @Name annotation to the class. While trying to show us how the Authenticator/login works, Norman tried to open components.xml. Unfortunately, this crashed Eclipse and 30 seconds later - following a bevy of "file does not exist" errors, we're back in action. To inject dependencies in a Seam environment, you use the @In annotation. In the example class, here's what the code looks like:

try {
  currentUser = (Person) entityManager.createQuery("select p from Person p where" + 
       " p.email = #{identity.username} and p.password=#{identity.password}").getSingleResult();
} catch (NoSuchEntityException e) {
  currentUser = null;
}

This example appears to encourage title coupling with the data layer, rather than loose coupling (i.e. a DAO layer). I'm sure Seam doesn't prevent you from developing a more loosely coupled application.

Bug Alert: The <h:messages> tag looks like it always has an <li> - even when there's only one message. Struts 2 has the same issue with its <s:errors> tag. It's disappointing that so many Java framework developers don't have more attention to HTML details.

Probably the coolest part of Norman's demo is how Eclipse auto-synchronizes with JBoss so he never has to start/stop anything when he changes Facelets pages or Java classes. Of course, hot deploy should be possible with any web application if you're using Eclipse Web Tools effectively.

I do believe all-in-one starter frameworks like Seam, Rails, Grails and AppFuse are excellent. However, I also believe they're solving a problem that only 10% of companies have. Most companies don't have the ability to start applications from scratch - unless they're a startup. Most companies have an existing infrastructure in place for the backend and they simply need a better web framework to slap a pretty face on it. I don't know the best solution for this, but it seems like a logical choice to RESTify the backend (possibly with a web framework) and then use a modern web framework for the front-end. IMHO, the best web frameworks for a RESTified backend are Flex, GWT and Appcelerator. If nothing else, these appear to be the most hyped for 2008.

Many of the enhancements that Seam has added to the Java web programming model are being pushed back into the Web Beans JSR. With Seam, injection is bi-directional (input and output), is continuous during application invocation and dis-injected after action is done. The whole purpose of this is to let Seam handle the state of your application. By not worrying about storing/maintaining state, you as a developer can concentrate on business logic more and get your applications done faster.

At this point, Norman started talking about Seam's events and how you can use them. Unfortunately, my battery ran out and I drifted off to do some other stuff. I'm sure Seam's Event Model is pretty cool, I just missed it.

AppFuse 2.0.1 Released

2007-11-26T09:29:43-07:00

The AppFuse Team is pleased to announce the release of AppFuse 2.0.1. This release squashes a number of bugs and includes an upgrade to Spring 2.5. To learn more about Spring 2.5's features, see InfoQ's What's New in Spring 2.5: Part 1 article.

For information on upgrading from 2.0, see the 2.0.1 Release Notes or changelog. AppFuse 2.0.1 is available as a Maven archetype. For information on creating a new project using AppFuse, please see the QuickStart Guide or the demos and videos.

What is AppFuse? Click here to find out.

The 2.0 series of AppFuse has a minimum requirement of the following specification versions:

Java Servlet 2.4 and JSP 2.0 (2.1 for JSF)
Java 5+

If you've used AppFuse 1.x, but not 2.x, you'll want to read the FAQ. Join the user mailing list if you have any questions.

Thanks to everyone for their help contributing code, writing documentation, posting to the mailing lists, and logging issues.

We greatly appreciate the help from our sponsors, particularly Atlassian, Contegix, JetBrains, and Java.net. Atlassian and Contegix are especially awesome: Atlassian has donated licenses to all its products and Contegix has donated an entire server to the AppFuse project. Thanks guys - you rock!

Please post any issues you have with this release to the mailing list.

Comparing Web Frameworks: Time for a Change?

2007-11-12T16:46:56-07:00

I first came up with the idea to do a "Comparing Web Frameworks" talk in 2004. I submitted a talk to ApacheCon and it got accepted. From there, I outlined, created sample apps and practiced this talk before ApacheCon. Believe it or not, that was my first time speaking in front of a large audience.

Historical note: October 2004 was a pretty cool month - I discovered Rails and Roller had a 1.0 release candidate.

When I created the presentation, it was in large part due to all the WebWork and Tapestry folks harassing me on this very blog. I started using Struts in June 2001 (the same month 1.0 was released) and had used it successfully on many projects. Part of the reason this blog became so popular was I posted lots of tips and tricks that I learned about Struts (and its related project) while using it. After a while, the noise became too heavy to ignore it - especially after I'd tried Spring MVC. So in an effort to learn more about the the other frameworks, I submitted a talk and forced myself to learn them. It seems to have worked out pretty well.

With that being said, I think it's time for a change. The reason I originally wrote this was to educate developers on how the top Java web frameworks differed and encourage developers to try more than one. A while later, I realized there's different tools for different jobs and it's not a one-size-fits-all web framework world. It's not a component vs. request-based framework world either. There's lots of options now. When I've delivered this talk earlier this year, I've always felt like I've left quite a few frameworks out. The solution could be to add more and more frameworks. However, I don't think that's a good idea. The talk is already difficult to squeeze into 90 minutes and it's unlikely that adding more frameworks is going to help.

The change I'd like to do is to reduce the number of frameworks down to (what I consider) the top web frameworks for deploying to the JVM. What are those frameworks? IMHO, they are as follows, in no particular order:

GWT-Ext
Wicket
Grails
Flex/OpenLaszlo
Seam
Struts 2

The RIFE, Tapestry and ZK folks can start bitching now. Sorry - less frameworks make for a more interesting talk. Maybe I'll add you in the future and I can ask the audience which ones they want compared then we can choose four and go from there. Why don't I mention Spring MVC? Because I think Struts 2 is easier to learn and be productive with and I also like it's more open and active community. I've written applications with both and I like Struts 2 better. As for Flex vs. OpenLaszlo, I'm somewhat torn. It seems like learning Flex is going to be better for your career, but it's likely useless without the Flex Builder - which is not open source. However, at $250, it's likely worth its price. I know the Picnik folks used Flex for their UI - I wonder how much they used Flex Builder in the process?

What do you think? Are these the top web frameworks for JVM deployment today? The next time I give this talk is this Thursday at ApacheCon. I may try to re-write my talk and then give the audience a choice of old vs. new. The downside of doing the new talk is I won't have time to write apps with GWT, Flex or Seam. Anyone care to post their top three pros and cons for any of these frameworks?

Flex and Grails Made Easy

2007-11-01T23:00:38-06:00

I love how easy it is to start new projects these days. It was very difficult when I started creating AppFuse way back in 2002. We've come a long way baby!

Here's a couple of easy ways to get started with Flex and Grails:

I hope to develop with Flex, Grails, GWT or YUI + Struts 2 in the next 6 months. These seem like the most exciting technologies for Java web development in 2008.

Introduction to Grails with Scott Davis at the Colorado Software Summit

2007-10-25T19:03:42-06:00

According to Scott, today's Java-based web frameworks are partial solutions at best. They're only solving one piece of the puzzle - you still need to manage persistence, deployment, etc. all by yourself.

We're moving into a new era of web frameworks. The expectation now is a full-stack solution. Grails is a fully integrated modern Java web application in a box. It contains Spring, Hibernate, Quartz, Log4J, Jetty, HSQL, JUnit and Ant. You're not limited to using Jetty, you can type "grails war" and create a WAR that you can deploy to any application server. In a single zip/tar, you get the whole thing - including the database and servlet container. You get a lot of good default for free, but you're not limited to those defaults.

What does "modern" in a framework mean? It means it uses Convention over Configuration - Grails autowires components together based on naming conventions. Struts 1.x uses Configuration over Configuration - the more XML the better.

The Wisdom of Crowds - why are the many smarter than the few? What is the wisdom of crowds when it comes to web frameworks. Struts is the wisdom of crowds when it comes to web frameworks. It's based on sound principles (MVC) and was written by Craig McClanahan. He was the architect of "Catalina" Tomcat 4 and wrote Struts shortly thereafter. David Geary was contributor #2 to Struts. It has a proven track record and has a 60%-70% market share. Struts must be the perfect framework - especially since it has such a great pedigree.

So what's wrong with Struts?

It's 7 years old
It's verbose and overly complex (reflective of the EJB 2.x era)
Splintered community: Craig moved on to JSF -> created Shale, then the WebWork merger
While Struts 1.x was an unqualified success, Struts 2.x can't seem to build that critical mass - it can't seem to reach The Tipping Point like Struts 1.x did

The Recipe for a Tipping Point: Contagiousness / viral, tiny "tweaks" to a proven model can yield big, disproportionate effects, the rise is not "slow and steady" - the effect is dramatic and immediate.

Ruby on Rails won the hype award. It's largely worth the hype, but it's not revolutionary - it's evolutionary. It has tiny tweaks to the proven MVC-driven approach: Convention over Configuration, Scaffolding and Unified Technology Stack.

The one thing that Rails is lacking is Java support. Grails, on the other hand, offers the same experience using known, proven Java solutions.

Rails => "replacement"
Grails => "upgrade"

Scott drank the Rails Kool-Aid for a while and enjoyed it, but found it difficult to switch from Ruby in the morning to Java in the afternoon. With Grails, he doesn't have to do as much context switching, as well as all the Java libraries are available - the ones you know and love.

You can drop groovy.jar into your classpath and write Groovy code. One nice thing about Groovy is you can rename your existing .java files to .groovy and they'll work just fine. Included Ajax support: Script.aculo.us and Protoype as well as YUI. YUI is battle-tested since it's used by Yahoo and very well documented. You can use "grails install-dojo" to install the Dojo toolkit. Grails has a wealth of plugins available at http://grails.org/plugins.

Now we're going to crack our nuckles and build some code - slides are over.

 grails create-app conference
 cd conference
 grails create-domain-class Speaker (add some fields)
 grails generate-all Speaker
 grails run-app

The impressive things about this set of commands is I was able to 1) download Grails and 2) run all these commands at the same time that Scott did. I was definitely impressed (I knew I would be). Auto-scaffolding - you can get the same thing as "generate-all", but it generates controllers and views at runtime in-memory. All you need to do is create a domain object (i.e. Talk) and then create a TalkController that has the following line in it:

def scaffold = Talk

As a test, I tried this at the same time that Scott did and got the following error. It looks like Grails/Jetty isn't smart enough to pick up new classes as they're added.

[263102] commons.DefaultGrailsApplication Class not found attempting to load class Talk
java.lang.ClassNotFoundException: Talk
        at java.net.URLClassLoader$1.run(URLClassLoader.java:200)

Grails comes with a number of environments. Dev (the default) auto-reloads changes to Controllers, Views and even the Model (this is helpful for rapid development). Prod loads all items statically for maximum performance. To change the environments - you can change DataSource.groovy.

For some reason, adding/removing some properties on my Talk object and my application hasn't been the same since. Now when I try to access my TalkController, I see the following stack trace:

org.springframework.orm.hibernate3.HibernateQueryException: could not resolve property: difficulty of: Talk; nested exception is org.hibernate.QueryException: could not resolve property: difficulty of: Talk
	at org.springframework.orm.hibernate3.SessionFactoryUtils.convertHibernateAccessException(SessionFactoryUtils.java:640)
	at org.springframework.orm.hibernate3.HibernateAccessor.convertHibernateAccessException(HibernateAccessor.java:412)
	at org.springframework.orm.hibernate3.HibernateTemplate.execute(HibernateTemplate.java:378)
	at org.springframework.orm.hibernate3.HibernateTemplate.executeFind(HibernateTemplate.java:342)
	at org.codehaus.groovy.grails.scaffolding.DefaultScaffoldDomain.list(DefaultScaffoldDomain.java:112)

I asked Scott about this error and he proved that removing properties from domain objects should work. I told him restarting Jetty didn't fix the problem and he suggested dropping the "Talk" table and letting Grails re-create it. Unfortunately, I have no idea where this database is, so that's difficult to do. Doh - now I realize what was causing the problem. Before I dropped the "difficulty" property, I had clicked on the column and that property was still referenced in the URL. When I'd refresh the browser, the stack trace occurred. I don't know if I'd consider this a bug or not.

dbCreate = hibernate.hbm2ddl.auto is used. When in development create-drop is used. In production and test environments, it uses update and saves the data between restarts.

You can turn off Hibernate's automatic schema alteration by commenting out "dbCreate" line in DataSource.groovy.

To run your application in Tomcat instead of Jetty, you can run "grails war" and copy the WAR to Tomcat. The WAR is created with the production environment by default, so you may need to pass in arguments or set environment variables if you want the WAR created in dev mode.

At this point, my battery died. Scott continued to cover how to order form elements (when using scaffolding) with "static constraints" and how to add validation rules. It was an excellent presentation and Grails definitely looks like a really cool web framework. The best part is I learned most of what you need to know to use it - in an hour!

I might have to try Grails soon - I love the concept of Life above the Service Tier and Grails would work nicely for serving up REST. I think YUI, GWT-Ext and Flex are probably the best frameworks for developing a SOFEA client. The question is - when using YUI, how do you download all pages in the application at once?

Maven Meetup in San Francisco tomorrow (Tuesday)

2007-10-08T22:55:41-06:00

If you live in the Bay Area and you're interested in talking with the inventors of Maven and/or XWiki, you should checkout the XWiki + Maven meetup at Terracotta's HQ. Java Open Source gurus Vincent Massol and Jason van Zyl will be there - sounds like a fun event!

AppFuse 2.0 Released!

2007-09-18T15:22:20-06:00

I'm extremely happy to announce we've finally finished developing AppFuse 2.0. The road to AppFuse 2.0 has been a long journey through Mavenland, annotations and generics. Thanks to all the developers, contributors and users for helping test, polish and prove that AppFuse 2 is an excellent solution for developing Java-based applications. Your time, patience and usage of AppFuse has made it the strong foundation it is today. Last but certainly not least, thanks to all the great Java developers who wrote the frameworks that AppFuse uses - we're truly standing on the shoulders of giants.

What is AppFuse? Click here to find out.

AppFuse 2.0 is available as a Maven archetype. For information on creating a new project using this release, please see the QuickStart Guide or the demos and videos.

If you've used AppFuse 1.x, but not 2.x, you'll might want to read our Frequently Asked Questions. If you have any questions or issues, please post them to the user mailing list. The Maven Reference Guide has a map of Ant » Maven commands. Maven for Newbies might also be useful if you've never used Maven before. There is some support for Ant in this release.

AppFuse 2.0 contains over 200 pages of documentation, downloadable as a PDF (3 MB). You can also download all its dependencies and install them in your local repository if you want to work offline.

For more information, please see the 2.0 Release Notes. The 2.0 series of AppFuse has a minimum requirement of the following specification versions:

Java Servlet 2.4 and JSP 2.0 (2.1 for JSF)
Java 5+

New features in AppFuse 2.0 include:

Maven 2 Integration
Upgraded WebWork to Struts 2
JDK 5, Annotations, JSP 2.0, Servlet 2.4
JPA Support
Generic CRUD backend
Full Eclipse, IDEA and NetBeans support
Fast startup and no deploy with Maven Jetty Plugin
Testable on multiple appservers and databases with Cargo and profiles

We appreciate the time and effort everyone has put toward contributing code and documentation, posting to the mailing lists, and logging issues.

We're also grateful for the help from our sponsors, particularly Atlassian, Contegix, JetBrains, and Java.net. Atlassian and Contegix are especially awesome: Atlassian has donated licenses to all its products and Contegix has donated an entire server to the AppFuse project. Thanks guys - you rock!

Comments and issues should be posted to the mailing list.

AppFuse 2.0 RC1 Released

2007-09-04T01:42:15-06:00

The AppFuse Team is pleased to announce the release of AppFuse 2.0 RC1! This release marks a huge step in the march to releasing AppFuse 2.0. This release puts the finishing touches on the AppFuse Maven Plugin (AMP), which offers CRUD generation, as well as the ability to change AppFuse from "embedded mode" to "full source" (like 1.x). In addition, we've addressed over 100 issues in preparation for the final 2.0 release. We hope to fix any bugs related to this release and release 2.0 Final in the next week or two.

The videos still represent how M5 works, but things have been simplified (now you don't need to run appfuse:install after appfuse:gen).

AppFuse 2.0 is available as a Maven archetype. For information on creating a new project using this release, please see the QuickStart Guide or the Hello World video.

If you've used AppFuse 1.x, but not 2.x, you'll want to read the FAQ. Join the user mailing list if you have any questions. The Maven Reference Guide has a map of Ant » Maven commands. Maven for Newbies might also be useful if you've never used Maven before. There is some support for Ant in this release.

For more information, please see the 2.0 RC1 Release Notes. The 2.0 series of AppFuse has a minimum requirement of the following specification versions:

Java Servlet 2.4 and JSP 2.0 (2.1 for JSF)
Java 5+

We appreciate the time and effort everyone has put toward contributing code and documentation, posting to the mailing lists, and logging issues.

We also greatly appreciate the help from our sponsors, particularly Atlassian, Contegix, JetBrains, and Java.net. Atlassian and Contegix are especially awesome: Atlassian has donated licenses to all its products and Contegix has donated an entire server to the AppFuse project. Thanks guys - you rock!

Comments and issues should be posted to the mailing list.

Update: I've uploaded a 247-page PDF version of the RC1 documentation to java.net. This PDF contains the relevant pages from the wiki that help you develop with AppFuse 2.0. Who knew I'd end up writing another book?

Want a kick-ass Java/UI Engineering Job in Mountain View?

2007-08-17T10:24:00-06:00

The last month working at LinkedIn has been an absolute blast. I'm new to the whole "treating developers like royalty" thing, so that's taken a while to get used to. It's definitely nice, especially when the company gives you ownership of the things you're working on. Sure, there's schedules and priorities, but it seems like each and every engineer has control of their own destiny. As a consultant, I've been very impressed with the way I've been embraced and folded into the team like a regular employee. There's lots of team lunches, a tech meetup every now and then, and I even played hoops with a bunch of guys last night. This is probably the coolest company I've ever worked for.

Wanna have fun like I am? LinkedIn is looking to hire quite aggressively over the next several months. There's new faces almost every week and hopefully I can "hook you up" to be a part of the festivities. Below is a position that we're currently hiring for in the UI Engineering team. Working remotely is not an option at this time, you need to live in (or relocate to) the Bay Area.

LinkedIn is an online network of more than 11 million experienced professionals from around the world, representing 150 industries. We are four years old, profitable and one of the fastest growing pre-IPO Web 2.0 companies in Silicon Valley.

LinkedIn is developing the UI infrastructure for our next generation applications. This is a strategic initiative that will enable LinkedIn to develop highly interactive and intuitive applications leveraging the latest Web UI technologies. We are looking for a world-class software engineer to work on this critical component of our infrastructure, in partnership with one or more technical leads, the engineering and the product team.

POSITION REQUIREMENTS:

EXPERIENCE:
- 3+ years of overall professional work experience
SKILLS & ABILITIES:
- In depth and hands on knowledge of Java, the J2EE platform and experience working with relevant tools (IDEs, ant, junit, etc.)
- A passion for UI frameworks: JSF and Facelets experience preferable.
- In depth knowledge of JSP, JSTL.
- Experience with Ajax.
- Experience with portal technologies.
- I18n experience a plus.
- Solid understanding of design, coding and testing patterns
- Ability to work in a fast paced, test-driven collaborative and iterative programming environment
- Ability to effectively interact with product managers and other organizational units such as QA and CS
- Excellent communication skills
EDUCATION:
- B.S./M.S in Computer Science or equivalent experience.

I don't know if JSF and Facelets experience is still a requirement (now that I'm here ), but a passion for UI frameworks and web development is. You should know at least two leading Java frameworks and have a lot of experiencing with testing web applications out-of-container. We're not looking for Java Developers turned web developers, we're more looking for Web Developers that know Java.

If this sounds interesting to you, shoot me your resume in an e-mail. Don't forget to include a link to your LinkedIn Profile.

Live Coding for 4 Days Straight

2007-05-24T13:50:30-06:00

Last week I had an interesting 4-day consulting gig for a client in Boulder. I was supposed to fly out to Connecticut to deliver a training course, but it got rescheduled due to the 45-day Vendor Approval Process I need to go through. The client in Boulder wanted me to come out and do an architectural assessment and provide recommendations. Topics they were interested in: web tier (specifically Spring MVC), Security, Ajax integration, build process, web services and localization. I've done this kind of before with Virtuas, but this time was different. With Virtuas, I'd do 5-days worth of presentations on just about anything the customer wanted. For example, checkout this agenda for a client in NY last year.

With the company in Boulder, I delivered zero presentations. Instead, everything we talked about and coded was hands-on. On Tuesday, we started out by discussing their application and some issues they were having. They'd done a lot of customization to Spring MVC and had managed to eliminate all the XML needed when adding new controllers and views. I spent 3-4 hours that day with 2 of their engineers finalizing and implementing their convention-over-configuration rules. On Wednesday, I helped them implement Acegi Security into their application. This was interesting because they didn't have any security mechanism and we had to implement Acegi from scratch and then tie it into their backend (using a custom AuthenticationProvider). We also integrated i18n so all messages were retrieved from their database.

On Thursday, we configured Ant to run their tests and wrote some tests for their controllers. As part of this process, I showed them how to use jMock and EasyMock and tried to explain the benefits of using Spring IoC (which they still aren't sold on). On Friday, we integrated Selenium into their build process and wrote a few tests using Selenium's Java support. In the afternoon, I showed them how they might use Scriptaculous and Prototype to Ajax-enable some features in their application.

Doing all the "live coding" on someone else's machine (with 5 developer's watching) was a bit nerve wracking. However, thanks to Cenqua's FishEye tool, I was able to search AppFuse and AppFuse Light's SVN repositories for code snippets and examples. While I knew how to do much of the stuff we covered, FishEye and Google bailed me out when I didn't. About halfway through, I realized that I don't keep a lot of my knowledge in my head. Instead, it's on this blog, or spread out on the web. I don't remember URLs anymore, all I remember are keywords. If I've read a blog post or article on the web, chances are I can find it again pretty easily with Google. Even though I store a lot of bookmarks in del.icio.us, I didn't use it all week. Remembering keywords is the new bookmark for me.

The whole week was an interesting exercise in "live coding." The whole team (6 or so) sat in a conference room all week and VNC'ed into the architect's box to do the work. We worked in Eclipse and used WTP to deploy/test things on Tomcat. The keyboard was passed around between developers at random and everyone got a chance to implement new features. I think the reason that everything worked so well was because the team was full of Senior Java Developers. Everyone learned from each other as they saw new shortcuts, keystrokes and ways or writing code. I don't know if this kind of thing will work in all development teams, but I'd encourage you to try it. It's a great way to share knowledge and educate the entire team on how a new module works.

Over the weekend, I received the following e-mail from one of the developers on the team:

Very nice to meet you this past week and get a chance to see firsthand the breadth and depth of your experience in web app frameworks and such. I believe due to your visit, we will be cranking happily along here very shortly. Everyone was quite happy with the results at the end of the day yesterday.

On a related note, if you're looking to hire an enthusiastic Web + Java Developer, please take a look at my resume or send me an e-mail. My current contract ends this month and I'm hoping to find something new to get me through the summer.

AppFuse 2.0 M5 Released - now with CRUD generation and XFire support

2007-05-23T17:49:10-06:00

The AppFuse Team is pleased to announce the release of AppFuse 2.0 M5! This release marks a milestone in the features of AppFuse 2.x. This release adds CRUD code generation, full source support (just like 1.x) and XFire integration. In addition, we've fixed all the issues related to switching persistence frameworks, and you should now be able to easily switch from using Hibernate to to iBATIS or JPA. The videos have been updated for M5. The Easy CRUD with Struts 2 video shows how code generation currently works.

AppFuse 2.0 is available as a Maven archetype. For information on creating a new project using this release, please see the QuickStart Guide or the Hello World video.

If you've used AppFuse 1.x, but not 2.x, you'll want to read the FAQ and join the user mailing list if you have any questions. The Maven Reference Guide has a map of Ant » Maven commands. Maven for Newbies might also be useful if you've never used Maven before. There is some support for Ant in this release.

For more information, please see the 2.0 M5 Release Notes. If you'd like to use AppFuse offline (or download everything at once), you may want to grab the dependencies and extract them into your ~/.m2/repository directory.

The 2.0 series of AppFuse has a minumum requirement of the following specification versions:

Java Servlet 2.4 and JavaServer Pages (JSP) 2.0
Java 5 for Development (Java 1.4 for deployment using the Retrotranslator Plugin)

Comments and issues should be posted to the mailing list.

We appreciate the time and effort everyone has put toward contributing code and documentation, posting to the mailing lists, and logging issues. We also greatly appreciate the help from our sponsors, particularly Atlassian, Cenqua, Contegix, JetBrains, Java.net and KGBInternet. Without them, working on this project wouldn't be nearly as much fun.

Update: The videos are much lower quality than the ones I originally recorded (13 MB vs. 70 MB). If you want to view the high quality videos (they're much clearer), you can download them from java.net. If someone has a better way to compress these (I just used QuickTime's Export feature), please let me know.

Also, this release contains the first release of the AppFuse Maven Plugin. This plugin is largely based on Hibernate Tools. We modified many of the FreeMarker templates from Hibernate Tools to default to certain annotations, as well as clean up the formatting. These templates are currently available in AppFuse's SVN. Hopefully making them available is enough to satisfy Hibernate's LGPL license.

Help me help you (market your web framework)

2007-04-26T13:58:30-06:00

Rather than trolling through google searches, mailing list archives and Amazon book searches, I'd like to try something new. For those projects represented in my Comparing Java Web Frameworks talks (MyFaces, Spring MVC, Stripes, Struts 2, Tapestry and Wicket), would you be interested in helping me gather statistics? I think by allowing projects to gather their own statistics, we'll get a more accurate number of their statistics. Here's the questions I need you to answer:

How many tools (i.e. IDE plugins) are available for your web framework?
How many jobs are available for your framework on Dice.com? What about Indeed.com?
How many messages where posted to your user mailing list (or forum) in March 2007?
How many books are available for your framework?

Of course, if you don't have time, I'll be more than happy to gather these statistics myself. However, those that do answer might get some extra marketing love during my talk. Answering in a comment or sending me an e-mail are the best ways to provide your findings. Thanks!

Update: Alastair asks for further clarification. Here goes:

> If you have lots of IDE tooling available, it probably means the configuration for the framework is overly complex and unmanageable without tooling.

While this may be true, if your framework is hot or uber productive, people want tools. Especially new developers. Remember there's a plethora of new Java developers every year and a lot of them prefer tool-based solutions. Good or bad, IDEs are nice and people like to use them. I've had many clients dismiss frameworks simply because no tools were available.

> The framework with the largest number of jobs available is probably Struts 1. Enough said.

Yes, you're definitely right. However, Struts 1 is not in this comparison - I dropped it because I don't want to recommend it to anyone.

> People only post to user lists when they are stuck. If the framework is hard to use, there will be lots of e-mails. If it has a steep learning curve, and/or the documentation is poor, this will be particularly so. On the other hand, an active list might point to a large active user base. Who knows which is which from a raw figure?

What about community? Mailing lists and their activity is a sign of an active community. Even though SiteMesh is a mature and good solution, its community sucks. There's little support, no new features, no bug fixes. An open source project w/o a community is tough for a company to adopt. Also, the best communities do a lot more than answer questions on mailing lists. They develop their applications, get advice, offer advice and sometimes even hang out. The Struts list used to have threads 30-50 messages long about development philosophies. When you joined the mailing list, you felt like you were a part of something, not just a user of a product.

> If your framework is fairly stable, and someone has written a fabulous tome on it that is universally acknowledged as "the bible", few people would bother writing another book for it.

I don't agree - this just means there's no market for other books because not that many people are using it. Look at Grails, Groovy, GWT and Rails - there's been quite a few books on each and no slowdown in sight. Then again, there weren't many Ant books and that was/is hugely popular. I'm willing to change this question to "How many good does your framework have?", but that's up to everyone's own interpretation. Again, lots of books means there's an active community outside the immediate mailing list - it's a sign the general "market" is interested and the framework fills a need.

Of course, I am interested in asking the questions that developers want to see answered. Do you have suggestions for replacement (or new) questions? Remember, people like hard facts, not wishy washy statements about how productive and OO your framework is. Every framework can be uber productive if you have the right developer(s) and they're genuinely interested in getting stuff done.

What web framework are you using with AppFuse?

2007-04-25T11:05:04-06:00

As part of my upcoming Comparing Java Web Frameworks talk, I'd like to show some statistics of web framework usage in AppFuse. Please vote for the one you're using by clicking on the link below. I'm mostly looking for current AppFuse users. By that, I mean folks that have used 1.x or 2.x on a project in the last 6 months, or plan on using it in the next month or two.

You'll need to create an account and login to vote. To do this, go to View > Account > Sign Up (after clicking on the link below).

http://appfuse.org/pages/viewpage.action?pageId=986

I'll compile the results of this poll on Friday morning (April 27th), so you have until then for your vote to be counted!

On a related note, if anyone knows how to get the monthly posting statistics from Spring MVC's forums, I'd love to hear about it. My "mailing list traffic" slide has excluded them for the past couple of years because I've been unable to get a count of monthly postings.

NOTE: If you vote by adding a comment to this entry, it won't be counted.

Update: Thanks to the 64 of you that voted. Here's the results of the poll:

As I said last time, I find the results interesting because AppFuse lowers the barriers and reduces the learning curve for all of these frameworks.

Equinox (a.k.a. AppFuse Light) 1.7.1 Released!

2007-04-21T17:27:33-06:00

Equinox 1.7.1 contains a number of dependency updates, and not much else. This will be the last release with the Equinox name. This project is changing its name to AppFuse Light and will be referred to by that name going forward. The project will be moving its source code to http://appfuse-light.dev.java.net. The equinox.dev.java.net project will remain because Cool URIs don't change. In addition to the name change, I'd like to try to merge the AppFuse and Equinox user communities. Since the technologies are so similar, and AppFuse 2.x will use some of Equinox's Ant scripts, it makes sense to bring these projects closer together.

In AppFuse Light 1.8, I plan on adding support for Stripes and Wicket as well as integrating the CSS Framework (like AppFuse uses).

50 possible combinations are available for download:

Web Frameworks: JSF (MyFaces), Spring MVC (with Ajax, Acegi Security, JSP, FreeMarker or Velocity), Struts 1.x, Struts 2.x, Tapestry, WebWork
Persistence Frameworks: Hibernate, iBATIS, JDO (JPOX), OJB, Spring JDBC

All of the frameworks used in Equinox, as well as most of its build/test system is explained in Spring Live. Going forward, documentation will be put on the AppFuse site.

A summary of the changes in this release are below:

Removed custom JavaScript and CSS for MyFaces Tomahawk's
Dependent packages upgraded:
- Ajax4JSF 1.0.6
- Cargo 0.9
- Commons Collections 3.2
- Commons DBCP 1.2.2
- Commons Lang 2.3
- Commons Validator 1.3.1
- DWR 2.0 RC2
- FreeMarker 2.3.9
- JPOX 1.1.7
- JUnit 3.8.2
- Hibernate 3.2.1
- iBATIS 2.3.0
- MyFaces and Tomahawk 1.1.5
- Spring 2.0.4
- Spring Modules Validation 0.8
- Struts 2.0.6
- Tapestry 4.1.1
- Velocity 1.5
- Velocity Tools 1.3
- WebWork 2.2.5

For more information about installing the various options, see the README.txt file. Live demos (thanks to Contegix!) are available at:

If you have any questions, please read the comments from the 1.7 release or ask them on the AppFuse mailing list.

Ant vs. Maven

2007-04-16T11:26:13-06:00

I found a good post from Steve Loughran on what's wrong with Maven's repositories. I agree with most of his points, but would like to point out mvnrepository.com. This site seems to provide good XML Feeds for what's been uploaded to Maven's Central Repository. If you're using Maven, you should probably subscribe to its Atom Feed.

In related news, Timothy M. O'Brien has an entry about Steve's upcoming book: Ant in Action. This book is the 2nd edition of Java Development with Ant. I have a hard time believing Erik Hatcher is helping Steve write Ant in Action - AFAIK, he's off in Rails-land enjoying himself. Regardless, I'm sure Ant in Action will be an excellent book. Java Development with Ant is one of my favorite technical books of all time and is largely responsible for inspiring me to write AppFuse. I read JDwA way back in October 2002 and used a lot of its code to develop AppFuse 1.x's Ant-based build system.

Like Tim, I still like Ant. However, AppFuse 2.x uses Maven 2 and most of the projects I work on these days use Maven 2. It may surprise some folks, but I actually like Maven 2 (not Maven 1). Sure it has issues, but after a year of using it in anger, I know how to solve most of its quirks. AppFuse 2.x users will benefit from this greatly and I'm thinking of changing its tagline to "We make Maven work."

One of the most interesting things about moving to Maven is we were easily able to make AppFuse more like a framework than a project starter kit. We thought this is what most folks wanted - especially the ability to upgrade a project to the latest version of AppFuse. While some folks wanted this, it seems like most folks liked the full-source version that was a pain-in-the-ass to upgrade. I don't blame them. On the project I'm on, I'll likely be converting to a full-source version before the project is over. That's why APF-675 exists. I doubt we'll make it happen for the 2.0 final release, but it is on our radar of things to do shortly after. With any luck, we'll create a way to migrate projects using embedded AppFuse to full-source AppFuse.

I'd also like to point out something ironic. With AppFuse 1.x, there were a lot of folks that advocated we move to Maven. Their primary reasoning - the Ant build scripts were too long and complicated. How about a good ol' lines of XML comparison for those folks:

Lines of Ant-related XML in AppFuse 1.x: 1655
Lines of Maven-related XML in AppFuse 2.x: 2847

Oh wait, that's not a fair comparison. The above number is for AppFuse in SVN, which end users won't deal with. A new project created with AppFuse 2.x will likely have a pom.xml with 634 lines. That's about 1/3 of the amount needed for Ant in AppFuse 1.x. Maven hasn't exactly gotten us away from XML hell though. How about a LOC count for archetypes vs. installers:

Lines of Ant-related XML for AppFuse 1.x framework installers: 2786
Lines of Maven-related XML for AppFuse 2.x archetypes (including archetype's pom.xml files): Too much to count. Creating archetypes is waayyyy too complicated IMO. Basic archetypes seem to be around 740 lines (pom.xml for archetype project, archetype.xml and archetype's pom.xml), modular archetypes are around 870. 740 x 4 + 870 x 4 = 6440. I'm guessing the full-source archetypes will add another 5000 lines of XML. Ugh.

This XML-for-archetypes comparison might be unfair as well. With 1.x, you could only create a webapp, with 2.x, you can create a modular application and chop off the web-portion if you so choose.

Of course, the real benefits of moving to Maven are elsewhere. We've seen quite an uptick on the mailing list in the last few months. There's tools cropping up and I've gotten quite a few inquiries about training (yes, I do have a 3-day course on Spring, Hibernate, Ajax, Maven and AppFuse). To me, AppFuse 2.x seems more complicated than 1.x, but it seems the community thinks otherwise. Judging from the increased amount of developer activity on the project, developers seem more interested in a Maven-based system too. Then again, we are making Maven work!

AppFuse 2.0 M4 Released

2007-03-24T16:33:21-06:00

The AppFuse Team is pleased to announce the release of AppFuse 2.0 M4! This release marks a milestone in the usability of AppFuse 2.x. A lot of folks (including myself) have been using AppFuse 2.0 on projects and have fixed quite a few issues. In addition to polishing the tutorials, we've fixed a fair amount of i18n bugs and packaging issues with modular archetypes.

We were hoping to get AMP's code generation and XFire integrated in M4, but were it's going to have to wait until M5.

AppFuse 2.0 is available as a Maven archetype. For information on creating a new project using this release, please see the QuickStart Guide.

If you've used AppFuse 1.x, but not 2.x, you'll want to read the FAQ and join the user mailing list if you have any questions. The Maven Reference Guide has a map of Ant » Maven commands.

The 2.0 series of AppFuse has a minumum requirement of the following specification versions:

Java Servlet 2.4 and JavaServer Pages (JSP) 2.0
Java 5 for Development (Java 1.4 for deployment using the Retrotranslator Plugin)

For more information, please see the 2.0 M4 Release Notes. To see how AppFuse 2.x works, please see the video demos.

Comments and issues should be sent to the mailing list.

Integrating Selenium with Maven 2

2007-03-09T10:35:04-07:00

I spent some time this past week integrating Selenium with Maven 2. This post is designed to show you how to do this in your Maven 2 projects.

First of all, there were two types of testing scenarios I wanted to make possible. The first was to allow HTML-based tests that web designers could create and run with Selenium IDE. As far as I know, Selenium IDE is capable of recording and exporting Java-based tests (powered by TestNG or JUnit), but I don't believe it's capable of playing them back. So for Java Developers, I wanted to allow them to write their tests in Java.

To get Maven to run HTML-based tests, the easiest way seems to be using the <selenese> Ant task. I tried Mavenium as well, but it 1) doesn't use the latest version of Selenium RC and 2) reports success when tests fail. Below is a Maven profile that I'm using in an AppFuse-based project to run HTML tests.

<profiles>
    <profile>
        <id>integration-test</id>
        <activation>
            <property>
                <name>!maven.test.skip</name>
            </property>
        </activation>
        <build>
            <plugins>
                <plugin>
                    <groupId>org.codehaus.cargo</groupId>
                    <artifactId>cargo-maven2-plugin</artifactId>
                    <version>0.3-SNAPSHOT</version>
                    <configuration>
                        <wait>${cargo.wait}</wait>
                        <container>
                            <containerId>${cargo.container}</containerId>
                            <!--home>${cargo.container.home}</home-->
                            <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>
                        </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>
                    <artifactId>maven-antrun-plugin</artifactId>
                    <executions>
                        <execution>
                            <id>launch-selenium</id>
                            <phase>integration-test</phase>
                            <configuration>
                                <tasks>
                                    <taskdef resource="selenium-ant.properties">
                                        <classpath refid="maven.plugin.classpath"/>
                                    </taskdef>
                                    <selenese suite="src/test/resources/selenium/TestSuite.html"
                                              browser="*firefox" timeoutInSeconds="180" port="5555"
                                              results="${project.build.directory}/selenium-firefox-results.html"
                                              startURL="http://${cargo.host}:${cargo.port}/${project.build.finalName}/"/>
                                </tasks>
                            </configuration>
                            <goals>
                                <goal>run</goal>
                            </goals>
                        </execution>
                    </executions>
                    <dependencies>
                        <dependency>
                            <groupId>ant</groupId>
                            <artifactId>ant-nodeps</artifactId>
                            <version>1.6.5</version>
                        </dependency>
                        <dependency>
                            <groupId>org.openqa.selenium.server</groupId>
                            <artifactId>selenium-server</artifactId>
                            <version>0.9.1-SNAPSHOT</version>
                        </dependency>
                    </dependencies>
                </plugin>
            </plugins>
        </build>
    </profile>
    <profile>
        <id>selenium-ie</id>
        <activation>
            <os>
                <family>windows</family>
            </os>
        </activation>
        <build>
            <plugins>
                <plugin>
                    <artifactId>maven-antrun-plugin</artifactId>
                    <executions>
                        <execution>
                            <id>launch-selenium</id>
                            <phase>integration-test</phase>
                            <configuration>
                                <tasks>
                                    <taskdef resource="selenium-ant.properties">
                                        <classpath refid="maven.plugin.classpath"/>
                                    </taskdef>
                                    <selenese suite="src/test/resources/selenium/TestSuite.html"
                                              browser="*firefox" timeoutInSeconds="180" port="5555"
                                              results="${project.build.directory}/selenium-firefox-results.html"
                                              startURL="http://${cargo.host}:${cargo.port}/${project.build.finalName}/"/>
                                    <selenese suite="src/test/resources/selenium/TestSuite.html"
                                              browser="*iexplore" timeoutInSeconds="180" port="5555"
                                              results="${project.build.directory}/selenium-ie-results.html"
                                              startURL="http://${cargo.host}:${cargo.port}/${project.build.finalName}/"/>
                                </tasks>
                            </configuration>
                            <goals>
                                <goal>run</goal>
                            </goals>
                        </execution>
                    </executions>
                </plugin>
            </plugins>
        </build>
    </profile>
</profiles>

The above setup will allow you to run Selenium tests in Firefox, and in IE as well when you're on Windows. I tried to get Safari to work on the Mac, but it just opens Safari and hangs.

HTML tests are great for non-programmers, but what about developers that prefer Java and want test reports to be included in the surefire-plugin's reports? That's easy enough. First of all, put your tests in a particular package so they can be excluded from the normal testing cycle. I used a webapp.selenium package. I configured the surefire-plugin to exclude these tests:

<plugin>
    <artifactId>maven-surefire-plugin</artifactId>
    <configuration>
        <excludes>
            <exclude>**/selenium/*Test.java</exclude>
        </excludes>
    </configuration>
</plugin>

Then I added the newly released selenium-maven-plugin to my "integration-test" profile and configured surefire to run the Selenium Java tests.

<plugin>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>selenium-maven-plugin</artifactId>
    <version>1.0-beta-1</version>  
    <executions>
        <execution>
            <id>start-selenium</id>
            <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>
            <id>surefire-it</id>
            <phase>integration-test</phase>
            <goals>
                <goal>test</goal>
            </goals>
            <configuration>
                <excludes>
                    <exclude>none</exclude>
                </excludes>
                <includes>
                    <include>**/selenium/*Test.java</include>
                </includes>
            </configuration>
        </execution>
    </executions>
</plugin>

Yeah, Maven can be quite verbose when configuring profiles. I contacted the Maven list to see if it's possible to simplify all this XML, but so far haven't found a solution.

If you'd like to see a pom.xml with the Selenium bits and a profile that runs both HTML and Java-based tests, click here (JavaScript needs to be enabled for this to work).

<build>
    <plugins>
        <plugin>
            <artifactId>maven-surefire-plugin</artifactId>
            <configuration>
                <excludes>
                    <exclude>**/selenium/*Test.java</exclude>
                </excludes>
            </configuration>
        </plugin>
    </plugins>
</build>

<repositories>
    <repository>
        <id>openqa</id>
        <url>http://maven.openqa.org</url>
    </repository>
</repositories>

<dependencies>
    <dependency>
        <groupId>org.openqa.selenium.client-drivers</groupId>
        <artifactId>selenium-java-client-driver</artifactId>
        <version>0.9.1-SNAPSHOT</version>
        <scope>test</scope>
    </dependency>
</dependencies>

<profiles>
    <profile>
        <id>integration-test</id>
        <activation>
            <property>
                <name>!maven.test.skip</name>
            </property>
        </activation>
        <build>
            <plugins>
                <plugin>
                    <groupId>org.codehaus.cargo</groupId>
                    <artifactId>cargo-maven2-plugin</artifactId>
                    <version>0.3-SNAPSHOT</version>
                    <configuration>
                        <wait>${cargo.wait}</wait>
                        <container>
                            <containerId>${cargo.container}</containerId>
                            <!--home>${cargo.container.home}</home-->
                            <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>
                        </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>
                <!-- Configuration to run Java-based Selenium tests -->
                <plugin>
                    <groupId>org.codehaus.mojo</groupId>
                    <artifactId>selenium-maven-plugin</artifactId>
                    <version>1.0-beta-1</version>
                    <executions>
                        <execution>
                            <id>start-selenium</id>
                            <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>
                            <id>surefire-it</id>
                            <phase>integration-test</phase>
                            <goals>
                                <goal>test</goal>
                            </goals>
                            <configuration>
                                <excludes>
                                    <exclude>none</exclude>
                                </excludes>
                                <includes>
                                    <include>**/selenium/*Test.java</include>
                                </includes>
                            </configuration>
                        </execution>
                    </executions>
                </plugin>
                <!-- End of configuration for Java-based tests -->
                <plugin>
                    <artifactId>maven-antrun-plugin</artifactId>
                    <executions>
                        <execution>
                            <id>launch-selenium</id>
                            <phase>integration-test</phase>
                            <configuration>
                                <tasks>
                                    <taskdef resource="selenium-ant.properties">
                                        <classpath refid="maven.plugin.classpath"/>
                                    </taskdef>
                                    <selenese suite="src/test/resources/selenium/TestSuite.html"
                                              browser="*firefox" timeoutInSeconds="180" port="5555"
                                              results="${project.build.directory}/selenium-firefox-results.html"
                                              startURL="http://${cargo.host}:${cargo.port}/${project.build.finalName}/"/>
                                </tasks>
                            </configuration>
                            <goals>
                                <goal>run</goal>
                            </goals>
                        </execution>
                    </executions>
                    <dependencies>
                        <dependency>
                            <groupId>ant</groupId>
                            <artifactId>ant-nodeps</artifactId>
                            <version>1.6.5</version>
                        </dependency>
                        <dependency>
                            <groupId>org.openqa.selenium.server</groupId>
                            <artifactId>selenium-server</artifactId>
                            <version>0.9.1-SNAPSHOT</version>
                        </dependency>
                    </dependencies>
                </plugin>
            </plugins>
        </build>
    </profile>
    <profile>
        <id>selenium-ie</id>
        <activation>
            <os>
                <family>windows</family>
            </os>
        </activation>
        <build>
            <plugins>
                <plugin>
                    <artifactId>maven-antrun-plugin</artifactId>
                    <executions>
                        <execution>
                            <id>launch-selenium</id>
                            <phase>integration-test</phase>
                            <configuration>
                                <tasks>
                                    <taskdef resource="selenium-ant.properties">
                                        <classpath refid="maven.plugin.classpath"/>
                                    </taskdef>
                                    <selenese suite="src/test/resources/selenium/TestSuite.html"
                                              browser="*firefox" timeoutInSeconds="180" port="5555"
                                              results="${project.build.directory}/selenium-firefox-results.html"
                                              startURL="http://${cargo.host}:${cargo.port}/${project.build.finalName}/"/>
                                    <selenese suite="src/test/resources/selenium/TestSuite.html"
                                              browser="*iexplore" timeoutInSeconds="180" port="5555"
                                              results="${project.build.directory}/selenium-ie-results.html"
                                              startURL="http://${cargo.host}:${cargo.port}/${project.build.finalName}/"/>
                                </tasks>
                            </configuration>
                            <goals>
                                <goal>run</goal>
                            </goals>
                        </execution>
                    </executions>
                </plugin>
            </plugins>
        </build>
    </profile>
</profiles>

NOTE: I used 0.9.1-SNAPSHOT of Selenium Server because it solves issues with the latest version of Firefox.

This brings up a related question I asked on the AppFuse mailing list a couple of days ago:

Do you use the Canoo WebTests? If not, how do you do UI testing? If so, would you prefer Selenium?

If you've tried AppFuse 2.x and have an opinion, please add a comment. Personally, I like Selenium, but I like how Canoo WebTest can be somewhat friendly to designers and allow i18n testing with Ant's property file support. With Selenium, you have to use parse/replace or Java tests to do i18n testing. Then again, if you need to test a lot of Ajax functionality, it's likely that Selenium will work much better for you.

RE: Jetty Ant Plugin

2007-03-08T08:13:08-07:00

It looks like Jetty has a new Plugin for Ant. If you've used the Jetty Maven Plugin, you know this is a slick way to quickly deploy your application. For those of you wondering about Tomcat, there's a similar Tomcat Maven Plugin that supports tomcat:run and tomcat:run-war. However, it's still in Mojo's sandbox.

I'm pumped to see this Jetty task for Ant because I've been thinking a lot about creating an exploded, full-source archetype for AppFuse 2.0. Of course, it's probably possible to start Jetty and monitor your project for changes w/o this task - but it does seem to make things a fair amount easier. If we do a full-source archetype, it makes sense to support Ant as well - especially since we can probably re-use the build.xml from AppFuse Light.

This brings up a related questions I asked on the AppFuse mailing list yesterday:

A couple of questions for folks using (or planning to use) 2.x:

1. As far as archetypes go, are you using basic or modular?

2. If there was a 3rd type of archetype that included the full source (like AppFuse 1.x), would you use it over the existing basic or modular archetypes? If yes, I'm assuming upgrading is not that big of an issue for you?

If you've tried AppFuse 2.x and would like to answer these questions, please add a comment.

There's another questions about Selenium vs. Canoo WebTest in that post, but that's reserved for another entry where I'll talk about Selenium options in Maven 2.

Artifactory - a new Maven 2 Repository Manager for Enterprises

2007-03-05T07:35:00-07:00

From the Maven 2 user list:

We would like to announce the immediate availability of Artifactory, a Maven 2 enterprise proxy.

Artifactory offers advanced proxying, caching and security facilities to answer the needs of a robust, reproducible and independent build environment using Maven 2. It uses a JSR-170 Java Content Repository (JCR) for storage, which makes it extremely easy to manage searchable metadata, and provide extended features such as security, transacted operations, auditing, locking, etc.

Artifactory is distributed under APLv2 at http://artifactory.sourceforge.net. It is currently available as a downloadable archive, that can be run out of the box (with default settings). An install script to run it as a Linux service is also provided. A (limited) guest live demo is available at http://www.jfrog.org/artifactory (username/password is guest/guest).

You are welcome to give it a go!

Cheers,

Yoav Landman,
The Artifactory Team

So how does this compare to Archiva, Proximity and Maven Proxy? One user writes (formatted for better reading):

My experience so far:

Archiva: Alpha; doesn't work (random webdav deployment failures), loads of bugs, low rate of progress. Feels dead.
Proximity: Works; slightly confusing (don't like the separation of metadata); lots of new releases constantly; hard to configure (hacking around with spring config files) - our install takes *forever* to restart.
m2proxy: simple, but simple.

Fingers crossed that artifactory hits the sweet spot...

It's interesting to see that Artifactory's UI is powered by Wicket and Dojo. The demo seems kind of sluggish, but I don't believe this application is meant to handle more than 10 users at a time. For more information on Artifactory's features, see its introduction page.

It's great to see a (seemingly) good tool come out for internal repository management.

I spent a couple days last week analyzing the best open source continuous integration server for Maven 2 projects. Hudson turned out to be the clear winner with the best UI and easiest setup. It also actually worked, which is a lot more than I can say for Continuum. While I did get Continuum to work, it required turning on anonymous SVN (no, putting the username/password in the URL did not work). CruiseControl worked as well, but required config.xml knowledge, which sometimes scares admins. Pulse and Bamboo continue to be the best commercial Maven 2 testers, while TeamCity failed my 10-minute test (twice!). One of the features I was looking for was Trac integration and that only exists for CruiseControl and Continuum.

It's amazing to see projects like Continuum and Archiva. If they're any reflection of the Maven team's ability to develop software, that's frightening. My advice: discontinue both of these projects as they're a waste of anyone's time to even research them.

Update October 2009: Fast forward a couple years and I take back what I said about the Maven's team ability to develop good software. Nexus is a kick-ass Repository Manager.

Java is more complicated than .NET ... unless you use AppFuse

2007-02-20T21:25:15-07:00

From Java to .NET, Back To Java Again, My Little Impression of The Two:

Having said all these, integration of various java projects together really do take a lot of Java people's time, it's no joke, but it's not desperate. For example, the open source project "AppFuse" does a fantastic job integrating various frameworks for us, I strongly encourage everyone to give it a shot and see how much time it saves you.

So which platform do I like? My impression is Java offers a lot flexibility and choices, but at the same time introduced the "Paradox of Choices", having so many things and integrate them together is no easy task, it simply overwhelm the human brains. .NET on the other hand is in a controlled environment, less choices, but easy to develop.

In other words: Java development is way more complicated than .NET ... unless you use AppFuse.

Database Profiles in AppFuse 2.0

2007-02-14T17:41:37-07:00

Last night, I added several database profiles to AppFuse 2.0 and its archetypes. What does this mean? It means AppFuse should work out-of-the-box with several databases, including:

H2
HSQLDB
MySQL
PostgreSQL
SQL Server

For example, here's how to test a new AppFuse project works with H2:

mvn archetype:create -DarchetypeGroupId=org.appfuse -DarchetypeArtifactId=appfuse-basic-struts -DremoteRepositories=http://static.appfuse.org/repository -DarchetypeVersion=1.0-m4-SNAPSHOT -DgroupId=com.mycompany -DartifactId=myproject

Yeah, I wish there was a way to shorten this command (or prompt for choices) too.

After doing this, you can cd into the "myproject" directory and run mvn integration-test -Ph2. AppFuse 2.0 projects are configured for MySQL by default, so if you want to permanently activate one of these profiles, you can add the following between the <id> and <properties> section of the profile.

    <activation>
        <activeByDefault>true</activeByDefault>
    </activation>

In addition to the profiles listed above, I tried to get Oracle Express and embedded Derby working. No dice on either one. I took a brief look at DB2 Express as well, but with a 400 MB download and 3 JARs required for its JDBC Driver - it seemed like a lot more trouble than it was worth.

Maven 2's build profiles are a powerful feature that we hope to make easy to use. For example, to test your new project with H2 and JBoss, you can simply run mvn integration-test -Ph2,jboss. Thanks to the power of Cargo, this will download JBoss 4.0.5, install it, and run all the Canoo WebTests within it. Of course, this will take a while the first time - especially since JBoss is a 77MB download. Fortunately, we allow you to change one small setting in your pom.xml and use an existing install instead.

Maven 2 is a kick-ass build/deploy/test tool once you figure it out. With AppFuse 2.0, we're doing all the "figuring out" for you.

NOTE: I would add more server profiles, but Cargo's Maven Plugin (version 0.2) has issues with Geronimo 1.1, Jetty 6.x and Resin 3.x. Strangely enough, Jetty's Maven Plugin version 6.0.0 works great, but 6.1.0 throws stack traces.

Update: Support for Oracle and Derby (in networked mode) has been added. We'll consider adding support for DB2 if IBM can figure out how to package their JDBC Driver into a single JAR.

AppFuse 2.0 M3 Released

2007-02-06T14:16:45-07:00

The AppFuse team is pleased to announce the release of AppFuse 2.0 M3! This release marks a milestone in our documentation efforts. We've completed all of the web framework tutorials and ensured that all the archetypes work properly. Turkish language support was added and native2ascii was integrated so all i18n bundles should work properly.

The major things missing from this release are code generation (AppGen) and web services (XFire) support. We hope to add both of these before the final release.

AppFuse 2.0 is available as a Maven archetype. For information on creating a new project using this release, please see the QuickStart Guide.

The 2.0 series of AppFuse has a minumum requirement of the following specification versions:

Java Servlet 2.4 and JavaServer Pages (JSP) 2.0
Java 2 Standard Platform Edition (J2SE) 5.0

For more information, please see the 2.0 M3 Release Notes.

We appreciate the time and effort everyone has put toward contributing code and documentation, posting to the mailing lists, and logging issues. We also greatly appreciate the help from our sponsors, particularly Atlassian, Cenqua, Contegix, JetBrains, Java.net and KGBInternet. Without them, working on this project wouldn't be nearly as much fun.