Editor's Desk

Wednesday Apr 29, 2009

Shale in the Attic

In case you hadn't heard, Apache Shale is moving to the Apache Attic. What is the Apache Attic? It's a new project, started last year. It's where other projects go to die.

According to the Apache Attic site:

It is intended to:

* Be non-impacting to users
* Provide restricted oversight for these codebases
* Provide oversight for active user lists with no Project Management Committee (PMC)

It is not intended to:

* Rebuild community
* Make bugfixes
* Make releases

Basically, if your community is dead or dying, your project is a good fit:

Projects whose PMC are unable to muster 3 votes for a release, who have no active committers or are unable to fulfill their reporting duties to the board are all good candidates for the Attic.

So, it looks like the Apache Shale developer community wasn't even strong enough to put out a release. I noticed things were quiet last year when I did a talk on the Shale Test framework at JSFOne -- the latest release was available, but no one had bothered updating the site.

If you're using Shale, don't worry too much -- as the above quotes state, the purpose of the Attic is to be "non-impacting" to users. Unfortunately, even though you'll still be able to get the bits, you can kiss any hopes of bug fixes goodbye.

What is Apache Shale?

If you're not familiar with Shale, it was one of the first projects that filled in holes in the JSF spec and added additional features such as an alternative templating mechanism, annotations, and a dialog framework. It was started by Craig McClanahan, the father of Struts and a member of the JSF 1.0 Expert Group, and originally intended to be a successor to Struts 1.0. As a matter of fact, originally it was a Struts sub project. However, the Struts community decided to merge with WebWork to form Struts 2, Shale became a top level Apache project, ant and the rest is history.

Shale includes several individual modules that could be used separately or together:

  • View Controller - Convenient mechanism to associate a "backing" Java class with each JavaServer Faces view in an application, with predefined event handlers for events significant to an application developer.

  • Dialog Manager - Mechanism to define a "conversation" with a user that requires multiple HTTP requests to implement, modeled as a state diagram.

  • Application Manager - Traditional application wide front controller features that should be applied to every request.
  • Validation - Integration with the Apache Commons Validator Framework, supporting both client side and server side validations based on a single set of configured validation rules.

  • Remoting - Server side support for applications that employ AJAX-style interactions.
  • Spring Integration - Integration with the Spring Framework, allowing the use of Spring's dependency injection framework to create JavaServer Faces managed beans.

  • Clay - An alternative to JSP where you define views in pure HTML, in a fashion similar to Tapestry and Facelets. An innovative sub-framework for supporting the configuration of reusable subtrees of JavaServer Faces components for customizable reuse.
  • Test Framework - Set of mock objects and JUnit test case base classes suitable for testing both the framework classes themselves, as well as application components built on top of the framework.

  • Tiger Extensions - Optional add-on library that adds additional ease-of-use features for Shale applications that run on Java Standard Edition 5 (popularly known by its code name during development, "tiger").

To learn more about Craig's perspective on Shale (among other things), check out this interview with Craig McClanahan.

What Happened?

The answer is quite simple: Craig lost interest and left the community.

Or, maybe it's a little more complicated: JBoss released Seam. Seam covers quite a bit of the same ground as Shale -- pretty much everything except Clay and the Application Manager. Facelets is a reasonable replacement for Clay (and more popular), and the Application Manager seemed pretty out of place from the beginning. Seam doesn't do Spring integration, but that has since been rolled into the main Spring distribution. It doesn't do client-side validation, but Ajax has diminished the demand for such a feature. Moreover, Seam is a cohesive product with the backing of JBoss and frequent releases and extensive tooling.

Seam is a full-stack framework (in other words, combined with EJB or JPA, it's all you need). However, MyFaces Orchestra provides conversation scope and view controller functionality similar to Shale, and other libraries such as MyFaces Trinidad offer some of these features as well.

So, without a driving force and facing a powerful alternatives, Shale lost its way. The most useful remaining portion, the Shale Test module, will find a happy home with the vibrant MyFaces community. Personally, I'm glad to see this -- I've spent a good deal of time, as have others, trying to move that project somewhere with a more active community.

I don't necessarily see this as a failure of Shale as a concept, though. Craig said the primary goal was to prototype new features for JSF 2.0. Perhaps it's fitting that JSF 2.0 will be out in just a couple months. And yes, many of the core features of Shale, such as annotations, resource resolution, additional scopes, and view controller functionality, and an alternative to JSP, will be in JSF 2.0. So, in some ways, Shale was a success after all.


Post a Comment:
  • HTML Syntax: Allowed