Don Brown wrote:
Well said Ted! I'll add that while my attentions have lately been mostly
towards getting WebWork 2 of the incubator and starting Struts Action 2,
I have been tracking this over the past few months, and really, it seems
to be taking a very long time. Broadly speaking, it's mostly just a
bunch of string replacements, isn't it? At least on paper, you have a
team with a dozen people or more. How can this possibly take so long?
Five months or more...
I certainly am not abandoning Struts Action 1. While all the activity might
not be apparent on this list, we've been hard at work migrating to a new
Maven 2 build so that we can get the next release, 1.3.2, out the door.
Well, changing build systems doesn't affect an end-user. As an end-user,
if somebody switches from using nmake to ant to build the exact same
code, why should I, as end-user care? Is this the best example of
forward progress on 1.x that you can offer? If not, what other things
are in the works?
In your own blog, Don, you make no bones about the fact that Struts 1.x
has not evolved significantly in the last 4 years. During most of that
time, it was not competing with 2 other "Struts XXX" for the attention
of you and other developers.
Given these basic facts, why should a rational observer think that there
is now going to be any significant forward movement on Struts 1.x?
Now, if there really isn't going to be any real progress there, well, I
think it's just wrong for you to be writing posts like this trying to
get people's hopes up. In that case, you should just tell them that
Struts 1.x is yesterday's tool, and encourage them to formulate their
migration strategies.
The new build will make it easier for extensions such as Streck to build and
integrate with Struts 1.x, and hopefully result in a better site layout and
more documentation.
I don't follow you....
Do not take the lack of new features to mean a lack of
interest. There are many other tasks required for project management, and
the development cycle is not always at the same stage.
I don't understand what the above means...
Could you clarify?
I am personally very excited about the Strecks project, as it fits into my
goal of developing a Java 5 annotation layer shared between Struts Action 1
and 2 that will allow apps to more easily make the transition.
Well, if you're excited by what Phil has been doing, why don't you just
immediately invite him to join the Struts project? Ted just wrote
something saying there are a lot of committers. The problem is that, I'm
sure that if you look at the list of committers, many of them have done
nothing for quite a long time. Why are they committers and somebody like
Phil, who is able and willing to do stuff, is out in the cold?
In the last month or so, I have asked pointed questions about why Struts
development stagnated. You yourself have accepted that the evolution of
Struts 1.x has stagnated over the last four years or so. If you have
basically an insider club made up largely of people who have done
nothing (for years even) and you don't take the opportunity to bring new
people in who are clearly able and willing, is there any mystery as to
the reasons for the lack of technical progress?
I cannot see any justification for this sitation, pragmatically -- OR
morally....
Once WebWork
2 gets out of the incubator, expect to see a flurry of activity towards Java
5 annotations, better error report, easier development models, and smoother
Ajax-enabling to name a few. I fully expect at least a few of these
features to trickle down to Action 1, as long as it doesn't disrupt the
continued stability of the project and code. In fact, as more of these
extensions like Strecks come to be, I wouldn't be surprised to see the
innovation flow in the other direction as well!
Well, if it takes you half a year to simply relabel Webwork as Struts,
how long will it take you to do substantive things as you describe
above? In particular, when you don't bring in new people to help when
the opportunity clearly arises...
Would a rational person be waiting for these innovations you describe to
emerge from your community, or would they go elsewhere -- Spring among
other things, for example?
The bottom line is, IMO, the Struts project hasn't been as good as it could
be at sharing our roadmap and vision with the user community.
Well, there is some element of bluff in the above statement, Don, isn't
there? You have admitted that there has been scant evolution in Struts
1.x for a period of 4 years or more. This would lead anybody to infer
that, over that period, there was no particular roadmap or vision.
You can't share your roadmap or vision if you don't have any to share.
Now, that said, there is sometehing promising in the above, which is a
willingness to recognize that you guys aren't perfect. And, as compared
to interacting with Ted Husted, say, this is an improvement in matters.
In that vein, Don, in your opinion, what are the primary reasons that
Struts 1.x development stagnated? You mention poor communication with
your user community. That is definitely a problem. What were the other
principal mistakes you made?
Jonathan Revusky
--
lead developer, FreeMarker project, http://freemarker.org/
It is a
personal goal of mine to improve this, and to see the continued success of
both projects.
I do appreciate all the feedback, both good and bad, we've received, and I
strongly encourage all involved in these "Struts Future" discussions to get
active - post bug reports and feature requests, submit patches, improve docs
on the wiki, etc. Struts is only as successful as its community of active
developers _and_ users.
Don
On 4/20/06, Ted Husted <[EMAIL PROTECTED]> 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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
