BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Interview: Patrick Lightbody on Project Able - A Complete Java Web Stack

Interview: Patrick Lightbody on Project Able - A Complete Java Web Stack

Bookmarks
WebWork committer, Patrick Lightbody, has announced Project Able: a complete Java web stack. Lightbody describes Able as:
it is an attempt to bring together quality opensource tools in one cohesive stack, similar to what Rails has done for Ruby, while also encouraging common practices I've used in software engineering for a long time ... It is very similar to projects such as Trails, Grails, and AppFuse. However, there are a few key differences:

  • The stack components are different (WebWork, Spring, iBatis, etc).
  • In addition to the basic framework, Able also encourages common development techniques and patterns (more below).

Project Able was started as a result of Lightbody's construction of HostedQA and BigBark. He realized the benefit in frameworks like Rails that provide the full stack of database layer, build infrastructure, and testing. The current incarnation of Project Able makes use of

Currently Project Able is available as a collection of code checked into the OpenSymphony sandbox SVN repository. InfoQ sat down with Patrick to discuss how Project Able stacks up versus similar Java efforts such as Grails and Trails. In response to our question of what justifies another Java web stack integration project when there are at least 3 similar others in development (Trails, Grails, and Appfuse):

Good question - clearly I'm generally in favor of collaboration and consolidation rather than competition. I've shown this with the merge of WebWork and Struts. In this case, I think we first need to break down the comparison a bit more. AppFuse isn't exactly a true competitor, since it is specifically designed to allow for choice of various framework components. This is something we are avoiding with Able. So that is why I didn't work on AppFuse.

Grails uses Groovy, which while nice, doesn't really give the developer the full power of Java's refactoring and debugging tools that I think are necessary. I would say Able is most similar to Trails, with the exception that it uses an action framework (WebWork) rather than a component framework (Tapestry). And that's OK: I think that it makes sense to have one or two of these types of frameworks for each style of web MVC framework.

With that said, I have already spoken with Matt Raible (AppFuse creator) and we agree that in the future Able might be pulled in to AppFuse. So we're keeping an eye on it. I think there is room for some level of competition here - more so that Ruby. That's because Java is a much larger community and therefore has enough strength to accommodate several ways to attack a problem. It's only when there become so many alternatives that some are almost the same thing with different names, as was the case with WebWork and Struts, that it becomes a problem.

We then asked Patrick about the recent trend of Java frameworks moving away from abstraction, abstraction, abstraction and back to tighter integration between components being used:
Yes, though I think it's not just Java that is changing: all of opensource is moving in that direction. More and more, we're finding projects that eschew use of lots of smaller libraries and instead re-implement some of the the basics themselves, such as logging or persistence. RIFE and Rails are perfect examples of these. But so is, for example, a trend of ditching things like commons-logging and instead using JDK logging or log4j directly. I think people are realizing that there are a ton of great libraries to use out there, but the tighter they are integrated the more efficient they will develop. That is specifically why I think Able will be a great starting point for web developers.

The conversation then turned to the obvious question of why iBatis:

No reason, really. My reasons for choosing iBatis were:

1) It fails fast when there is a misconfiguration, which fits in to my philosophy about how a framework should work.
2) I like the control over the queries, especially with regards to joins and one-to-many and many-to-many relationships.

I haven't tried Hibernate 3 or JPA, so perhaps they will be good replacements. I'd be open to trying them out, provided that I can still implement all the same features that are in Able, including the ability to reload the Hibernate configuration on the fly.

Finally, in terms of one feature that is a key selling point of the Project Able stack:

the upgrade feature embodies the entire development philosophy of Able. It does two things: it brings attention to an all-too-often pain point in software development (upgrades) and also shows how you can enhance the "checkout and go" philosophy to apply to even your database changes.

Rate this Article

Adoption
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • Why not struts?

    by karan malhi,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Why not have struts as an MVC framework? I thought webwork and struts were working together for struts 2.

  • Re: Why not struts?

    by Patrick Lightbody,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Good question - Struts 2.0 will be integrated in place of WebWork very soon!

  • Re: Why not struts?

    by Pete the Wheat,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Afaik, Struts 2 is going to be more like Webwork than Struts "1" but it isn't yet released, not even a beta. Maybe that's why. :)

  • Convention Over Configuration

    by Ben Rometsch,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Is there any chance of these convention over configuration changes being factored back into WebWork/Struts 2? It would remove 80% of most xwork files I would have thought, and make development a little faster...?

    Also, what about the REST based URL aspects? This would be a great addition to WebWork for those that dont want the full Abl stack...

    Great idea for a project tho. Appfuse/Equinox have helped enormously and could do with some company!

  • Full Stack - The community is finally getting the message

    by Shimon Amit,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    We're seeing it with Grails and JBoss Seam, and now Able. This is great. Thank you Ruby on Rails.

    Also, please include scripting at some point. It helps makes life easier. Yes, refactoring and tooling are important, but if there is demand, there will be supply. It's one of the basic rules of life.

  • Re: Convention Over Configuration

    by Patrick Lightbody,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Ben,
    Absolutely - I hope to get the AbleActionMapper and AbleConfiguration stuff in to Struts 2.0. We've discussed it and I hope Able will help make it happen faster.

  • iBatis

    by Marc Tremblay,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I'm currently moving a project off of iBatis to JPA. I'm amazed that anyone wastes their time with iBatis.

    Seriously, JPA isn't so complicated.

  • Re: iBatis

    by Patrick Lightbody,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Marc,
    I definitely want to take a look at JPA - I've heard good things!

  • Re: iBatis

    by Marc Tremblay,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    If it's any help, we're using Spring 2.0 to provide standalone JPA to servlets. However, we are sticking to pure JPA in our code (not using any extra Spring features) such that we could easily move to another JPA container if we need to down the road.

  • Re: iBatis

    by graham o'regan,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I like the direction JPA is heading, but I think Sun have made the usual mistake of not releasing enough in the first version and they don't have a "release often" strategy so we aren't going to see any improvements soon. To be really useful, JPA needed to have Hibernates Query *and* criteria API.

    As with Spring & IoC - use the standards if your company force you, but use Spring and Hibernate if you want the very best (not necessary latest) features. The last two contracts I have had have used Java 1.4 for a start :(

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT