Struts Ti (short for Titanium) was a codename for Struts 2. In late November 2005, the Ti proposal was amended to include a merger with Open Symphony WebWork. Pursuant to this plan, WebWork 2.2 was donated to the ASF in March 2006, and the active WebWork committers joined the Apache Struts Project. The WebWork codebase was brought into the ASF through the Apache Incubator. The donated codebase is now part of the Apache Struts Project.
WebWork started as a Struts Revolution. Over the years, it has evolved into a superb action-based framework that retains many Struts 1 paradigms.
People who have worked with both Struts 1 and WebWork 2 tend to agree that it was the logical candidate for Struts 2. If you had looked at the Struts 1 roadmap and the WebWork 2 feature set, you'd see that WebWork has already did most of what we had wanted the Struts framework to do. If we had finished the original Struts 1 roadmap as written, Struts 1 would have ended up being a WebWork 2 workalike. Rather than reinvent the wheel, Ti became a proposal to put the WebWork wheel back on the Struts axle.
At this point, the Ti codename has been dropped, and we are referring to the donated codebase as Struts 2.
The Struts 1.x release series is deeply into "backward compatibility" mode. In fact, backward compatibility has become an obsession with Struts 1. Before making any API change, we deprecate the existing member, and make at least one milestone release before removing the deprecated member. Each Struts milestone is drop-and-go compatible with the last. Maintaining this degree of stability takes a lot of effort, but given the installed base, we feel it is worth the time and trouble.
There were several proposals for a new Struts 2 codebase. The first formal proposal was Jericho, followed by Shale, and then Ti. Jericho never progressed past the trial balloon stage. Shale is based on JavaServer Faces, and, when the time came, the Apache Struts PMC found that many of us were not ready to adopt JSF just yet. Initially, Shale was a Struts subproject, but later Shale graduated to its own top-level ASF project.
The Ti proposal includes the idea of collaborating with other projects to build a "best of breed" framework that incorporates everything we have learned over the past six years. The original Ti proposal included technology developed by Apache BeeHive, Spring, and OpenSympony WebWork. In the course of co-developing the initial Ti codebase, the WebWork team offered to "join forces" with the Apache Struts group, so that we could work more closely together. Out of these collaborations, the Apache Struts/OpenSymphony WebWork merger arose.
For additional background, see My History of Struts 2.
For the time being, there is no plan to migrate XWork to to the ASF. Struts has always had many dependencies on external packages. So long as projects like XWork and SiteMesh are doing well at OpenSymphony, there is no reason to change venues. Of course, if another OpenSymphony project were ready to join the ASF, our door is open.
Struts 2 is designed to be simpler to use and closer to how Struts was always meant to be. To Struts 1 developers, Struts 2 feels strange but familiar. For more, visit the Struts 2 homepage.
Struts 2 is stable, featureful, and ready for primetime. It's the direct descendant of WebWork 2, and we have dubbed the 2.0.x series the "compatiblity release". The bits themselves are ready-to-go. We're just finishing-up on peripheral concerns that don't affect the code itself, and new, optional features that don't affect the existing feature set.
In Struts 2.0.x, we won't be straying far from the path WebWork 2 has already blazed. WW2 powers some of the greatest web applications on the planet, including Confluence and Jive Forums. There's no arguing with success!
A "General Availability" release of Struts 2 is now available. It is very compatible with WebWork 2, but offers several new features. WebWork 2 is still available, although it is uncertain whether there will be many new releases of WebWork.
Of course, WebWork 2 is going to be supported for some time to come, just as Struts 1 will be supported. Both products have a robust user community, and many of us have mature projects in production that will never be migrated to a new major release.
No.
Essentially, Struts 2.0 is the technical equivalent of WebWork 2.3. Aside from the package and property renaming, it isn't much different than, say, migrating from WebWork 2.1 to 2.2.
No.
There is a robust and vibrant community of developers using Struts 1 in production, and we expect that thousands of teams will continue to base new projects on Struts 1, and continue to support existing projects, for many, many years to come.
New and improved extensions for Struts 1 continue to appear regularly. In 2006 alone, we saw releases of Hoople, Strecks, JSP Control Tags, Sprout, Spring Web Flow, DWR, Calyxo, FormDef, and Java Web Parts. There are dozens of books and hundreds of articles available to help people get started with Struts 1 or improve the application they already have.
Since the merger, Struts 1 has gone on to release a new minor version, Struts 1.3, and new 1.x releases are being planned. Struts 1 continues to be the most popular and best supported web application framework for Java.
Of course, if you are starting a new project, and have your choice of frameworks, this might be a good time to consider whether you would like to continue to use Struts 1 or whether it's time to try Struts 2.
We do not recommend migrating stable Struts 1 applications to Struts 2, unless significant new development is planned. Struts 1 will be supported for some time to come, and there is no reason to rework code that already works.
If new features are being added to an existing application, the Struts 1 and Struts 2 codebases can coexist in the same application. Struts 1 actions can handle the *.dos and Struts 2 can handle the *.actions. Once a team is committed to Struts 2, one way to stage a migration would be to migrate one action at a time (until there's nothing left to do).
For help with migrations, see the Struts 2 Migration Guide.
Five reasons to migrate:
Five reasons not to migrate:
Struts 2 supports JSF components, so it's not an either/or proposition. For a complete JSF solution designed with Struts developers in mind, see Apache Shale.
The overall direction of Struts 2 is to continue to become the framework that we actually want to use to build our own applications. Sometimes that means supporting J2EE technologies, like JavaServer Faces. Sometimes that means creating our own technologies, like Interceptors, the Value Stack, and Taglib Themes.
Struts Classic is a codename for the work we needed to do to create and release the seven components we extracted from Struts 1.2. It is not a product per-se, but shorthand for the 1.3.0 build of the seven components.