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
- WebWork web MVC framework
- SiteMesh for web page decoration
- Spring IoC container
- iBatis OR mapping framework
- TestNG unit testing tool
- EasyMock mock object library
- Maven build tool
- Jetty for quick deployment during development
- HypersonicSQL for an in-memory database during development and testing
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.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: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.
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:Finally, in terms of one feature that is a key selling point of the Project Able stack: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.
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.