Raible Designs

[ANN] Equinox 1.4 Released

This release is mainly to support Spring 1.2.1 and Hibernate 3.0.5. The default database is now PostgreSQL because of an issue with Hibernate 3 and HSQL. All of the frameworks used in Equinox, as well as its build/test system is explained in Spring Live. Detailed release notes are below:

- Added "typeMismatch.java.util.Date" key to messages.properties (for Spring) to display a friendly error for invalid dates.
- Changed to use PostgreSQL as the default database because of an issue with HSQL and Hibernate 3.0. Read more »
- Added "clear" target to build.xml for clearing out the database.
- Added MySQL JDBC Driver and jdbc.properties.mysql for easy switching to MySQL.
- Changed UserWebTest (jWebUnit test) to get lastInsertedId from UI using HttpUnit rather than using UserManager (Richard Easterling).
- Changed spring-sandbox.jar to springmodules-validator-0.1.jar since Commons Validator support for Spring has moved to the Spring Modules project.
- Changed all Spring XML files to use new "value" and "ref" attributes.
- Dependent packages upgraded:

• Cargo 0.5
• Log4j 1.2.9
• Hibernate 3.0.5
• iBATIS 2.1.0
• OJB 1.0.3
• Spring 1.2.1

Download. For more information about installing the various options, see the README.txt file.

Demos:

• Spring
• JSF
• Struts
• Tapestry
• WebWork

The basic Equinox download contains all the various web and persistence framework options in the "extras" folder. If you have issues replacing the web or persistence framework (or both), please enter an issue in JIRA and I'll build and upload a customized version for you.

RE: AppFuse, 'tool' of experts

I'm please to say that I've been biled yet again. The first time wasn't so bad, and this time seems pretty mild too. There's no mention of asshat, chozgobbler or turdburglar in the whole post, which is somewhat disappointing. Nevertheless, it's what I've come to expect from a guy who sallies car bombs and dances like a sissy.

Regardless of the lack of bile in Hani's post, he does bring up some good points. Let's take a look at them individually:

• IzPack and MyJavaPack: the progress bar doesn't work, and the installer downloads everything rather than just including/installing it all.
  • To be honest, I didn't know it was possible to pack up everything and skip the internet download part. I'll definitely look into fixing this.
• You must have Tomcat installed to work with AppFuse.
  • This is true, and I've thought about changing it to be Resin friendly, or possible Orion friendly, but there simply hasn't been any demand. Of course, Orion isn't that attractive to many folks because it doesn't even support Servlet 2.4. Maybe you should crackin' on that Hani! Or maybe you just like living in the dark ages with your affections for EJB 2.1, Servlet 2.3 and WebWork 1.4.
• When creating a new project, you get prompted for the package name twice.
  • This is true, and something we should fix. The major reason we haven't is because I didn't want to distribute a 2MB BeanShell JAR that would support the 3 lines of code to fix the problem. I guess I should bite the bullet and add the bloat, or figure out a more elegant way to fix the problem. Issue #75.
• Project generation auto-detects MySQL when you don't have it installed.
  • MySQL is the default, but it's pretty easy (IMO) to use PostgreSQL or Oracle.
• I'm a web monkey.
  • True, but that's cool now with Ajax and all.
• Half the build targets don't work.
  • I think this is more like a handful don't work, but good effort. I agree we should remove the install-* targets when installing a web framework. Issue #76.
• Every object creates builder objects in hashCode and toString.
  • This is true, and I've seen no performance implications from it. In reality, these are a product of the commons-lang project, as well as Commonclipse. We should probably change these to use smarter methods like the ones IDEA generates. It'd be nice if Eclipse has hashCode() and equals() method generation like IDEA.
• The project's directory layout is bound to confuse a seasoned webapp veteran.
  • The directory structure is largely based off the example app in Java Development with Ant. Since AppFuse uses Ant, I figured it was a good idea to use a "best-practices" structure like Erik describes in his book. I've often thought about consolidating the 3-source tree, 3-test tree directory structure to one, but users are very attached to the current setup. Maybe for 2.0.
• XDoclet generates web.xml.
  • I agree that using 11 XML fragments to generate 1 XML file is a little ridiculous. You're right - developers should know how to write a web.xml and what goes where. Issue #77.

Thanks for the feedback Hani - sounds like I owe you a car bomb or two at JavaOne.

AppFuse cost $78K to develop

I somehow stumbled upon Koders.com this morning, where they have a cost-of-development based on LOC in the project's CVS repository. Apparently, AppFuse has cost around $78K to develop. Here are a few other project costs I discovered:

• Cocoon - $287,750
• MyFaces - not listed
• Struts - $490,040
• Spring - not listed (add to index form - I'd do it, but I'm not a developer on the project)
• Tapestry - $278,185
• WebWork - $109,025
• Ruby on Rails - $181,985

Are these costs accurate? Probably not, but it's still an interesting indicator.

[ANN] AppFuse 1.8.1 Released

This release is mostly a bug fix release with no new features. It also includes many upgrades to the core libraries (Hibernate, Spring, iBATIS, MyFaces). Thanks to all the sponsors who have contributed products and free hosting to the AppFuse project. You guys rock!

• Download
• Release Notes
• Learn more about AppFuse

To see how AppFuse works, please see the following demos:

• Demo of Features in Flash
• Struts + Spring + Hibernate
• Spring + iBATIS
• WebWork + Spring + Hibernate
• JSF + Spring + Hibernate
• Tapestry + Spring + Hibernate

Comments and issues can be sent to the mailing list or posted to the AppFuse Issue Tracker.

AppFuse 2.0: JDK 5, Annotations and JSP 2.0

For the most part, I haven't used JDK 5 on any of my recent projects. You can compile and run AppFuse with JDK 5, but it doesn't use any JDK 5 features. After doing a code review at Bouvet last week and seeing how much cleaner their code is with Generics, Varargs and the Enhanced for Loop, I think it's time to dig in. I don't know how soon we'll start, but I think it's time to start creating a branch for AppFuse 2.0 - which will use these features. For AppFuse 2.0, I'd like to go whole hog, bleeding-edge and use all the stuff that's out there to make developer's lives easier. This includes JSP 2.0, Annotations (especially for Hibernate and Spring, as well as Tapestry) and all the JDK 5 features that seem useful.

Since most developers won't be able to deploy on a JDK 5-compliant server for quite some time, we'll continue to maintain the 1.x branch as JDK 1.4-compliant. I expect to release AppFuse 1.8.1 later this week (with mostly bug fixes + latest releases of Hibernate/Spring) and 1.9 in the next month or so. From there, we'll likely do 1.9.x releases with bug fixes and do all the major upgrades (i.e. Tapestry 4.0.x) in the new branch. Working with new features in JDK 5 should be a lot of fun.

I'm hopeful that we can get rid of XDoclet and we may even give Maven 2 a run for its money. Last week in Norway, I found that most Java developers were using Maven on their projects and I also discovered that many of the core Maven 2 developers are getting paid to work on it full time. There were even claims that Maven 2 is going to be twice as fast as Ant - which definitely intrigues me.

Later: I just realized the hardest part of this migration is going to be replacing AppGen. It currenly uses XDoclet templates for all the class templates - and we'll need a new solution based on annotations. Oh well, it's kind of ugly anyway, but it'll likely be difficult to figure out a new solution. Hopefully we can create some sort of tool that involves easy-to-customize templates and a GUI to drive it all.

Java Jobs: broken down by web framework

I updated my Web Framework Comparison presentation today. Rather than updating the graph that shows today's job availability, I did one that compares today to 6 months ago. Struts is still the clear winner (and growing). Spring is definitely growing. Tapestry has about the same amount of jobs (9 vs. 8). WebWork lost 10 opening (down to 4) and the demand for JSF skills has grown as well.

Is WebWork a dying framework? I've heard folks complain about its small community, and there still aren't any books is only one book about it. Is that a jab at Patrick, Jason and Kris - or a jab at Manning? I'm not sure. The good news is WebWork in Action and WebWork Live should both be out this summer.

My search criteria for all of these was "framework and java" from the front page on dice.com. I did filter a bunch out for WebWork b/c there's some product called "WebWorks" that folks want to hire for.

In my own experience, these numbers are not as accurate as you might think. Since I gave my original presentation, I've been contacted a number of times to work on projects. It's about even between Struts, Spring MVC, WebWork and JSF. I haven't had a single inquiry to do Tapestry development. The bad part about Struts jobs is there's so many of them, that rates are likely pretty low (i.e. 35-45/hour), whereas the others can get you upwards of 80-90/hour.

So what do these numbers mean? Do they mean you should tailor your learnings and skills to the most popular frameworks? In a sense, it's important to do so. If nothing else, Struts skills are import so you can migrate all the Struts applications to your favorite framework. However, I don't think these numbers are that important when choosing a framework to start your project with. I think the most important thing in choosing a framework is passion. Which one do you want to work with the most? It's likely that your productivity will be higher if you're enthusiastic about the framework, rather than bored with all the skills you've accumulated using it. Then again, if you're motivated by productivity more than enthusiasm - using your skills to crank out applications quickly is probably a good idea.

You might think that the number of skilled developers for framework X is important too. I don't think it is. I think the most important thing is to hire smart developers. A good developer can come up to speed on any framework in 2 weeks and be highly productive in 4 weeks. If not, the developer isn't that smart or the framework isn't that good.

Just for kicks, I did some searching for other web frameworks as well:

• Rife: 0
• Wicket: 0
• Echo: 3
• Ruby on Rails: 1
• ASP .NET: 2876

Now the question is - what kind of rates are these skills getting? I'd like to know what the average Rails and ASP .NET developers make. In Denver, Java developers seem to make between 65-85/hour when they're experienced contractors.

[Colorado Software Summit] Spring and Comparing Web Frameworks

I'm pleased to announce that I'll be speaking at the Colorado Software Summit in October. I'll be doing a presentation on Spring and one on Comparing Web Frameworks. The abstracts are on my very own speaker page. I've never been to this conference, so I'm definitely looking forward to it - especially since it's only an hour away from my house. The only downside to the conference (for speakers) is you have to deliver each presentation 3 times. Of course, this is great if you're an attendee. Now I just need to figure out a way to get SourceBeat to sponsor my condo for the week.

I originally did my Web Frameworks Comparison (PDF) last year at ApacheCon. I'm looking to revamp it this year - so please let me know if have any suggestions for improvements.

[OSCON] AppFuse Tutorial and Spring MVC vs. WebWork

Now that the OSCON 2005 site is up, I might as well advertise the two things I'm doing: an AppFuse Tutorial and a session titled WebWork vs. Spring MVC Smackdown with Matthew Porter. I wasn't planning on doing the AppFuse Tutorial, but I was asked to do it - so what the heck. The title has "Struts" in it, but I'm willing to do whichever one (JSF, Struts, Spring MVC, Tapestry or WebWork) the audience chooses. If we're good, maybe we'll have an Eclipse Plugin done by this conference to simplify the new project and code generation process.

AppFuse Demos moved to demo.appfuse.org

I bought the appfuse.org domain name sometime last year. I haven't done anything with it for the most part and I've just pointed it to this site. It's amazing how many people actually use it - it's my 4th largest referrer! The demo site I have at Kattare (demo.raibledesigns.com) has a whole slew of demos installed on it, so I contacted Keith (at kgbinternet.com) to set me up a new domain for AppFuse-only demos. These can now be found at http://demo.appfuse.org or by clicking on of the URLs below. The site is currently running AppFuse 1.8 with JDK 5 and Tomcat 5.5.7.

• Struts + Spring + Hibernate
• Spring + iBATIS
• WebWork + Spring + Hibernate
• JSF + Spring + Hibernate
• Tapestry + Spring + Hibernate

The "Issues" link on this site won't work yet - I'm in the process of setting up JIRA at http://issues.appfuse.org. Hopefully we'll have it done sometime this week. Contegix has been gracious enough to offer free hosting of AppFuse's JIRA instance.

Update: AppFuse's JIRA is now up. Thanks again to Atlassian for a great product and to Contegix for hosting it. The quick installation and support from Contegix has been outstanding.

How do we bake Ajax into Struts and Spring MVC?

I see a trend happening here. The next version of WebWork, as well as Tapestry and JSF are all embracing Ajax technologies. By "embracing", I mean they're not only using them, but they're making it easier for us to use them.

After using XmlHttpRequest in my last two projects, I think this is a must for Struts and Spring MVC as well. The technology is very cool and customers absolutely love it.

The question is how do we bake it in? WebWork makes it easy because its tag libraries are backed by customizable Velocity templates. With Struts and Spring MVC, it seems the best way would be to use tag libraries, but maybe there's better alternatives. Do they each need an AjaxAction/AjaxController or something that allows DWR-type stuff?

What are your thoughts? You might argue that using DWR should suffice, but w/ everyone else (even Rails) baking it into the framework - I see no reason why Spring MVC and Struts shouldn't do the same. You are using these frameworks to develop kick-ass UIs aren't you?