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.

Monday Apr 20, 2009

Oracle and Sun: JSF Comes Full Circle

So, the big news today is that Oracle is buying Sun. This is definitely the biggest thing to happen to Java since it's original release (not to mention the rest of Sun's portfolio). Overall, I believe Java is in pretty good hands. Oracle has bet their entire non-database business on Java. It's their lingua franca, the basis of the Oracle Fusion Middleware stack, which includes the entire BEA portfolio (WebLogic, Tuxedo, JRockit, etc.), JDeveloper, Coherence, and tons of other development and server products. More importantly, Fusion Middleware is the technical foundation of Oracle's next-generation Fusion product line, which includes their original business applications, plus PeopleSoft, Siebel, and JD Edwards applications.

The Fusion applications are built using Oracle ADF Faces Rich Client, and run on Fusion Middleware. So, not only is Java central to their application stack, but so is JavaServer Faces --- ADF Faces Rich Client is a suite of JSF components, built on top of the open source Apache MyFaces Trinidad component suite. ADF Faces Rich Client is so important for Oracle's strategy, they even have a site to explain how these new "Rich Enterpise Applications (REAs)" work.

So, I think we can all rest assured that JSF is in good hands -- it's a core piece of Oracle's strategic foundation. IBM, on the other hand, has less incentive to care. However, they've been making quite a few improvements to Rational Application Developer's JSF tooling over the past few releases, and they have also been contributing to MyFaces 2.0. So, given the fact that they already have quite a few JSF customers, and it's gaining market share, I don't expect that to change too much. I don't think things will change too much for JBoss/Red Hat, either, except they may no longer enjoy such a close relationship with Sun.

What's funny about the JSF RI becoming part of Oracle is that in many ways, the framework is coming full circle. JSF 1.0 was heaving influenced by Oracle UIX. ADF Faces Rich Client is, in essence, a very advanced version of UIX.

Time will tell how well this merger works out, which product lines will survive, and so on. No doubt, the landscape has changed. Let's just hope that Oracle improves the Java Community Process instead of ditching it, and that the platform remains as open and prevalent as it is today (or even more so).