Raible Designs

Don Brown Makes Maven 2 Not Suck

Don Brown spent some time over the weekend Making Maven 2 not suck:

While there are a few (very important, I might add) things Maven 2 gets right, there are a bunch that just suck, yet I use it at my day job (Atlassian) and in Open Source work, so in true Open Source tradition, rather than continue bitching, I'm doing something about it. I'm embarking on a quest to fix all the bits of Maven 2 that really annoy me and waste my time. I hope to get most, if not all, of the changes back into the codebase, but my personal deliverable is a build of Maven 2 that doesn't suck.

On his blog, Don lists a number of improvements he hopes to make. This weekend, he implemented the first three, which concentrates on speeding up remote repository access and downloading of artifacts.

First up, tasks #1-3. I implemented these changes in a bored Sunday afternoon and saw a example build (Struts 2 core) go from 3 minutes, 26 seconds to 2 minutes even, so a little over 40% performance improvement.

Interested, I decided to try Don's improvements on AppFuse. Since it fetches seemingly hundreds of artifacts from Maven's central repository, it seemed like a good testing ground. With a clean repository (rm -r ~/.m2/repository), a 8 MB/sec internet connection and "mvn -Dmaven.test.skip", I achieved the following results with the stock version of Maven 2.0.8:

[INFO] Total time: 7 minutes 40 seconds
[INFO] Finished at: Mon Jan 28 09:02:11 MST 2008
[INFO] Final Memory: 55M/508M

With Don's improved uber-jar, I received the following results:

[INFO] Total time: 5 minutes 17 seconds
[INFO] Finished at: Mon Jan 28 09:10:56 MST 2008
[INFO] Final Memory: 56M/508M

460 vs. 317 seconds = a 31.1% improvement -- Nice work Don!

When he implements #4 (Should support artifacts checked into the SCM in the lib/ directory so no external repository needed), I'll be a much happier Maven consumer. I've always wanted the ability to bundle all of AppFuse's dependencies for offline use like we did in 1.9.x.

Don - I'll buy you numerous beverages in Vegas if you add the ability to run a Maven command to put all a project's dependencies in its lib directory too.

Shadowbox - a slick Lightbox that supports Flash

Via Ajaxian, I learned about Shadowbox.js. From its creator, Michael Jackson:

A few weeks ago, I was looking for a Lightbox-like script that would allow me to display more than just pictures. In addition to static images, my client required the ability to display various types of movies including QuickTime and SWF. The only script that fit the bill was Lightwindow?a nice piece of work to be sure?but it required the Prototype + Scriptaculous combo and I was already using YUI.

Besides, I thought, it would be really great to have a full-featured media viewing application that was library agnostic. Then, if I need to use a different framework for some particular reason, I can easily switch.

Thus was born Shadowbox?a cross-browser, cross-platform, cleanly-coded and fully-documented media viewer application built entirely in JavaScript.

I've been using Lightbox JS on this site for almost 2 years. The next time I need lightbox functionality for an application, I'll definitely try out Shadowbox. I dig the look and feel. I agree with Ajaxian commentors that rel="lightbox[name]" would be awesome. If it's added, I could theoretically replace lightbox.js with shadowbox.js and I wouldn't have to make any other changes.

View Shadowbox Demos »

What are the must see places and things to do in Dublin and London?

A good friend sent me an e-mail this afternoon asking for some advice.

I am headed to London & Dublin next week for a quick trip with my friend who's a pilot for US Airways. I am pretty sure you've visited these 2 places, let me know if you have any good advice or must see places or things to do, or even a good place to stay. We haven't booked any hotels yet but booked our flights.

I haven't been to Dublin since 1998 and I've never been to London - so I figured it might be a good question for readers of this blog. What are the must see places and things to do in Dublin and London? Thanks in advance for any advice you can offer.

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

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?

Ext JS Tag Library

James Carr in Making extJS More Accessible to Java Developers:

With my recent interest in extjs, I was playing with the idea of making a Struts2/WebWork component library or a tag library to handle a lot of the boilerplate extjs code (i.e. creating layouts and such) but, luckily, discovered someone beat me to the punch!

I randomly came across ExtTLD this morning while sifting through my rss feeds, and I must say I am rather impressed. Although I consider myself a pretty good javascript developer, there seems to be a lot of java developers who aren?t that hot at javascript... which is why whenever I attend any java related conference there is always several sessions touting "javascript free ajax!" frameworks like GWT, Ajax4JSF, or IceFaces. Although I've always been skeptical of such frameworks, I do see their benefits... especially for the java developer who excels at serverside JEE development but generally sucks when it comes to adding javascript behavior to the presentation layer.

I can definitely see how Ajax-with-IDE-code-completion would appeal to many developers. However, I do have to agree with James:

So far it looks good, but I haven't had a chance to play with it yet. Basically, I'll have to see if it passes my "good javascript generator framework" test. I?m a pretty staunch advocate of unobtrusive javascript, and generally hate any presentation layer framework that seeks to dump several hundred (or thousand) lines of javascript inline in the html document.

For development shops that have UI-only developers for the front-end and Java developers for the controller/validation part of an application, frameworks that generate JavaScript usually don't make sense.

ExtTLD's license:

ExtTLD is published under GPL 3.0 license however restricts use by companies participating in animal abuse, such as animal testing laboratories etc.

Migrating a Rails app to Grails

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.

A Positive Wicket Experience

Julian Sinai recently released the first version of his company's product based on Wicket. In A Year of Wicket, he describes the experience (emphasis mine).

I've been working with Wicket for almost a year. We've just released our first product that uses Wicket for the user interface, and so it seems like a good time to take stock. Unfortunately, it's not a public site, it's an installable enterprise product, so I can't show it to you. If you don't want to read further, here's the executive summary: Wicket rocks!

I was hired as the GUI Architect for this project. I came to it with many years of GUI experience, mostly using Swing, but without a lot of web development experience.

Because of my Java and Swing background, I was drawn to Wicket. It maps fairly closely to the Swing model of development. So does GWT, but when I evaluated it, it seemed so different from other J2EE frameworks that I felt it was a step too far. No HTML, and no WAR files, for example. This made my colleagues nervous, who were used to Struts and PHP. Me too, as a matter of fact.

I had done some pretty serious prototyping for another project with Tapestry, and there were certain things I liked, like runtime bytecode generation. But the learning curve was pretty steep. At one point I needed to create a custom component, and to do so I needed to learn about engine services and other arcane things that I felt made the process too hard. By contrast, custom components are Wicket's bread and butter, and they are very easy to build.

I also took a close look at JSF. It seemed overly complex to me, and not much of a departure from the Struts era. It came across as a technology designed by committee, with the combination of several complementary libraries required to get the job done, and there are still too many configuration files.

So we decided to use Wicket.

...

One of Wicket's advantages is the strict separation of design from behavior, that is, HTML from code. While we did not have a web designer on the team who built the HTML (the developers did this), and therefore didn't get any mileage from the separation in that sense, we definitely gained from having all the behavior in Java code, because it gave us all the power of refactoring, compile-time error checking, and maximum reusability. [Read More]

I really like how Julian talks about reasons they didn't choose other frameworks. Beyond that, I think it's important to note that Wicket was a perfect fit for someone with heavy Java and Swing experience. I still think Wicket is a little verbose for Web developers that program in Java (me), but it's unlikely there's very many of those. Building a form in Java seems so much more cumbersome than building it with HTML - but that's probably just me.

FreeMarker vs. JSP 2

I've been doing quite a bit of prototyping with Spring MVC and Struts 2 with both JSP and FreeMarker in the last few months. I'm trying to migrate a proprietary servlet-based framework with a proprietary JSP compiler to something that's open source. There's a couple of important features that the proprietary view framework has:

1. It's expression language allows methods to be called with arguments.
2. Templates can be loaded from a JAR on a remote server.
3. XML in variables is escaped by default.

For #1, I've found this to be impossible with JSP EL or JSTL. I've created JSP functions that allow argument passing, but they don't allow overloading of functions. FreeMarker solves #1.

For #2, JSPs again fail because the templates have to be on the file system or in a WAR. FreeMarker solves this problem as well.

For #3, neither JSP or FreeMarker solve this problem. I realize it can be fixed in FreeMarker by hacking the code - I've done the same with Tomcat and solved it for JSP as well.

So based on the requirements in this project, FreeMarker is the clear winner. Here's some problems that I see with using it:

• No XML escaping of expressions by default
• No compile-time checking of expressions
• IDE support is limited to Eclipse (meaning very little in the way of code-completion)

FreeMarker users - are there other problems you've experienced when using FreeMarker in your applications?

RE: Why Grails doesn't use Maven

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-id

My 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.

GWT Presentation with Bob Vawter

Tonight I'm in Mountain View attending the inaugural meeting for the new Silicon Valley Google Technology User Group (SV-GTUG). The good news about this meeting is Bob plans to discuss some of the new features in the GWT 1.5 release. Although it is not available yet, it sounds like they are putting the finishing touches on the 1.5 release and that it will be available soon.

The first ting I've learned is that GWT is actually pronounced "gwit". Bob is a member of the GWT team and he's the only one that's not based out of Atlanta. GWT has a very Swing-like programming model. It has widgets, panels and windows and operates very much like a traditional UI programming API. To create an application, you create a class that implements EntryPoint. Below is an example Hello World application.

One of the really nice things about GWT is that you can easily debug your application in your favorite Java IDE. GWT doesn't prevent you from writing JavaScript - you can insert native JavaScript into your code using a special /*-{ script here }-*/.

When you compile a GWT application, you get a whole bunch of stuff. When trying to develop cross-browser JavaScript code, you often end up with "if soup" to handle the different browsers. GWT does the same thing, but it creates different versions of the application for the different browsers. The naming of these files is an MD5 hash that's bootstrapped by a simple JS file. GWT files are all static and the file sizes are ~40KB/each for the Hello World application.

If you have to write fewer than 100 lines of code, it's likely that GWT will be overkill - you can do it with JavaScript easier. Once you get more lines of code and larger teams, Java's tools do all the heavy lifting. Yes, you can create large applications with large teams with scripting languages, but Java is the clear winner when you have large teams of developers working on projects.

GWT provides a RemoteService for client code and a RemoteServiceServlet for server-side code that you can use to implement RPC calls. For more information, see the Remote Procedure Calls documentation.

At this point, we're 45 minutes into the presentation and it's pretty disappointing. This is likely because there's no presentation and Bob doesn't seem to have any sort of agenda. I think this type of presentation would work well if folks had experience with GWT and were asking lots of questions. However, it seems that most folks haven't used GWT - so the questions (and his resulting answers) aren't very meaty.

One attendee asked about making GWT applications SEO-able. Bob's suggested solution is to continue to use Servlet or JSPs to render the page, but then use GWT to for the user interaction that needs to happen within the page. The RootPanel class has a get(String id) method that can be used to put the GWT application into a particular div or other placeholder.

Google Base and Google Checkout are currently using GWT. There's also a lot of Google internal development that uses GWT. Apparently, there's quite a few applications built with GWT that haven't launched yet.

Has anyone used the Maven Gwt Plugin? It sounds like it might be pretty nice as it contains the GWT compiler with no OS-dependent Google tooling.

The main new feature in GWT 1.5 is Java 5 support. There's also a GWT Incubator that's used to host GWT features that may go into GWT's core. You can view the demos online.

GWT's mission statement:

GWT's mission is to radically improve the web experience for users by enabling developers to use existing Java tools to build no-compromise AJAX for any modern browser.

GWT's competition according to Bob - Visual Studio.