As we all know, Struts has evolved in recent times from being a just a
framework to being a "community" supporting two "separate but equal"
frameworks which have nothing to do with each other except a shared
name, and perhaps a couple of shared committers.
I think the message that is going out to the wider community is quite a
confusing one. For users, it's not terribly helpful that the individual
frameworks are on the same web site and on the same mailing list. 99%
(or some number close to this) of users will be interested in one or the
other frameworks - the rest of the documentation, messages, etc. is just
noise. The situation is made even more confusing by the WebWork merger.
Because 1.x is not going to disappear overnight, Struts is effectively
hosting three separate frameworks - Struts, Action 1, and Action 2.
My view is that this process needs to be formalized. Struts has already
become an umbrella body for the three frameworks, but there needs to be
a clearer separation between them in the way that they are managed, or
at least, in the way information about the projects is made accessible
to users.
And now for my second point which I have not expressed before because it
only occurred to me last night ...
Since evolution of Struts from just a framework into an umbrella body is
already underway, why limit it to hosting "two separate but equal
frameworks". Why should Struts not become *"*three* separate but equal"*
frameworks, namely
1) Struts Shale
2) Struts Action 2, that is, the outcome from the WebWork merger
3) Struts Classic (or whatever you want to call it), the original Struts
that we all know and love
Yes, instead of replacing the original Struts, why shouldn't Struts
Classic be allowed to evolve properly in its own right, instead of in
the cramped 1.x space as a relic of the past. For me, at least, Strecks
(http://strecks.sourceforge.net/) proves that the assumption that Struts
Classic cannot be evolved to support a more advanced, modern programming
model is flawed. While mandating support for Java 5 is obviously no
option for Struts 1.x, I don't see why it should not be an option, for
example, for a Struts Classic 2. A Struts Classic 2 could also be a bit
more adventurous in introducing changes, for example, to ease
configuration, but would still need to be backwardly compatible, or at
least allowing for a relatively trivial migration.
I think this proposal is one in which everyone could win.
Those who think that Struts Classic is too fundamentally flawed and
should be just allowed to die, period, can move on to Struts Action 2 or
Shale now. By adopting WebWork, the Struts community would be formally
recognising the merits of this framework, and would make it more easily
accessible for existing Struts users. However, it is not a move that
users should be forced into prematurely. Many organisations which
already have a significant investment in Struts Classic would surely
much rather see from the Struts community a genuine effort to evolve the
current framework in a way which is backwardly compatible, than to be
forced into a switching to a new framework with all the associated costs
of migration and retraining.
I think that the leaders of the Struts community have a responsibility
to the hundreds and thousands of existing users to give them as much
choice as possible, and not to close the door prematurely on any options
which could make sense to a lot of people.
Ted Husted wrote:
On 4/19/06, Alexandre Poitras <[EMAIL PROTECTED]> wrote:
Second, all the comitters have answered your questions very nicely
Yes, we have. Here's a handy summary for future reference:
The Apache Struts project continues to move that the same pace we
always have. We generally run 18 months to 24 months between release
series. The Struts 1.3.x series has already begun, and a 1.3.0 build
is available for testing. From the beginning, there were several teams
that started after us and issued a 1.0 release before Struts 1.0 came
out in June 2001. Other teams do move faster, but faster is not always
better.
We add committers on a regular basis. We use the same protocols as all
other ASF projects. (Right now, there are about thirty active ASF
projects with almost two thousand committers.) ASF projects look for
"people that we believe are devoted to the task and match the human
attitudes required to work well with others, especially in
disagreement". There are no "lead developers" on ASF projects. Every
binding vote counts as much as every other. Voting aside, everyone is
invited to donate patches and participate in the development
discussions. Some ASF projects always post a patch before committing
it. We aren't asking anyone to do something that we wouldn't do
ourselves.
We do *not* consider other projects "competitors". We consider
ourselves colleagues who are trying to solve the same problem in
different ways, in search of better solutions. The Apache Struts
website links to several similar projects, like Wicket and Spring MVC,
and our FAQ encourages visitors to look for the solution that best
serves their own needs. The ASF alone has five web application
framework projects. In the data persistence area, we have four
products now, and a fifth is in the Incubator. For us, it's not about
"competition", it's about a community of developers working together
to find different ways to solve our own problems.
For Apache Struts 2.0, we've had three formal proposals. One of those
turned in to a subproject, Shale (which is nearing a stable release).
Another, Ti, evolved into a merger with one of our colleague projects,
WebWork. As we worked on Ti, which was based on XWork, the lead
WebWork committers mentioned that they would like to join forces with
another framework. At first, Don and I thought that "joining forces"
meant that we would start a new project, but Patrick and Jason wanted
to join Apache Struts instead. So that's the path we followed. We are
not interested in reinventing the wheel. All we want to do is create
and maintain the frameworks that we want to use to build our own
applications.
We do have committers who remain interested in the Struts Action 1.x
codebase. We have 1.x applications in production, just like everyone
else. Most of these applications would not be migrated to Action 2,
but would be maintained in their current form. (I have a stable
application that is based on Struts 1.0, and it works just fine, thank
you very much.) Of course, like anyone else with Action 1.x
applications, the committers are going to be interested in new
extensions, like Strecks, as well as proposals and patches as to how
to continue evolving the 1.x codebase. Anyone actually following
Struts 1.x development knows that we do accept and apply patches on a
regular basis.
In the field, I find that many teams have standardized on Struts 1.1,
and have no wish to change. Struts 1.1 is solving their problems, and
until they have new problems, they are happy campers. Personally, I
don't believe that most teams don't want to update their web
application more than once every two years. It was not our intention
to move slowly, but, in retrospect, I believe that a calm and steady
pace is one reason Struts 1.x remains the most popular web application
framework for Java.
New and improved extensions to Action 1 continue to appear regularly.
In *2006* alone, we've seen the release of Strecks, JSP Control Tags,
Sprout, Spring Web Flow, DWR, Calyxo, FormDef, and Java Web Parts.
There are dozens of books and literally hundreds of articles available
to help people get started with Action 1 or improve the application
they already have.
For more, see the Apache Struts roadmap FAQ
* http://struts.apache.org/roadmap.html
HTH, Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
