Little did anyone know, when the first few lines of code were committed to the Struts CVS repository in June 2000, that a revolution was brewing. Prior to that time, there were few useful models for best practices for the architecture of web based applications. The best we could do was handwaving about "Model 1" and "Model 2" approaches.
The original implementation of Struts, which was released as a 1.0 product approximately one year later, changed all that. As more and more people came to understand the advantages of building on top of a stable and supported framework, and as more and more developers adopted it for their own application development, and as more and more books helped everyone understand how to use the framework correctly, and as more and more development tools provided support for building Struts based applications, the word changed. A small open source project became a defacto industry standard that, even today, is very popular.
But that was then ... and this is now. In the years that Struts has been around (five and counting as of this writing), vastly improved technologies have become available from many talented architects and designers. Moore's Law has continued its seemingly inexhaustible progress. Developers have grown in their ability to understand the benefits of a monolithic controller architecture ... as well as increasingly developing preferences towards agility, code reuse, unit tests, and building applications by composition instead of inheritance.
One of the critical success factors for Struts has been, and continues to be, an obvious commitment on the part of the Struts developers towards backwards compatibility. This has led to Struts being both praised (for protecting the investment of developers with thousands of applications critically dependent on the framework) and dissed (for being a dinosaur compared to all the "latest and greatest" favorite technological approaches). History has shown, in terms of its continued popularity, that this is a good strategic approach.
But, it is also time to harvest many of the great ideas that have matured in the last several years. It is time to base a web tier framework on top of the new standard API in this space (JavaServer Faces), and eliminate the need to implement redundant features, instead of just treating JSF as a UI component technology. It is time to answer the question "if we knew then what we know now, what would Struts have looked like?"
Thus, Shale is a modern web application framework, fundamentally based on JavaServer Faces, and focused on improving ease of use for developers adopting JSF as a foundational technology in their own development environments. At the same time, the architecture of Shale is a set of fine grained services (and service options) that can be combined as needed to meet particular application requirements, rather than a monolithic request processor that is hard to customize and extend. In addition, integration links for other frameworks and framework components are provided, to ease development when combinations of technologies are required.
EDITOR'S NOTE: Why "Shale"? As others have pointed out, the cultural rules of engagement at Apache encourage both evolution and revolution in software designs. Revolutions are typically assigned code names while they are under discussion, gaining access to the branding of the overall project once they are accepted (or, going off on their own if they are not). Other proposals for Struts 2.x have talked about tearing down the walls inside the framework, and those are Good Things. Shale's architecture, on the other hand, is based on the principle that we should fundamentally divide the notion of a web application framework into solid individual layers, much as we see geologically in shale deposits around our volcanoes and coastlines. Each layer of the framework should focus on the specific requirements that are relevant to that layer -- and use of one layer should not necessarily require the use of all the rest (although it's certainly reasonable for synergies to exist if all the layers are chosen :-). Hence, "shale".