On 9/10/05, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: > Over the past few months there have been a number of people who have > attempted to evolve Struts to "catch up" in some ways with what other > frameworks are doing. They have been turned away, sometimes for > obviously legitimate reasons, sometimes for more debatable ones.
Usually, the problem has been retaining backward compatibility. When a suggestion breaks backward compatibility, we tend to pass, at least until we can setup a deprecate/ remove/ release cycle. Since this cycle can take a year or more, some people drift away before we can implement a suggestion. Some suggestions have been out of scope, mainly for the taglibs. Along the way we decided that the original taglibs should stick to the HTML 4.1 specification. Some taglib suggestions are non-starters because of the product's scope. The big fix for both of these problems, and several others, is to subdivide the one-size-must-fit-all Struts distribution into subprojects. If a suggestion is not backwardly compatible, then perhaps we can make it an optional component in the Extras subproject. If a taglib is not HTML 4.1 compliant, then maybe we can start another taglib subproject. But, until last month, we simply didn't have the infrastructure to even consider such things. Another problem is being sure that there be someone around to maintain the code. We like to see broad enough support for any suggestion to ensure that there will be at least three people around who will support the code. It doesn't matter if comes from a developer or a committer. A lot of suggestions from committers die on the vine because too few people seem interested. Many folks don't realize that extensions we now take for granted, like Validator and Tiles, were being used in production applications for *years* before we added them to the distribution. (I used both myself in April 2001, before Struts 1.0 final.) In the same light, I expect we will see an Ajax subproject for Apache Struts one day. But before that happens, we'd like to see broad support for Ajax among Struts users. Then, we can be sure there will be committers around to support the subproject later. As it stands, we are just now completing tasks we planned *18 months* ago. But, we are completing them, slow and steady. In fact, I remember Don Brown making the first "subproject reorganization" commits at ApacheCon 2004 last November. Martin and I were sitting at a table with him at the Hackathon, jovially giving Don verbal +1s. :) Ten months later, we're finally at the point where we can build and distribute the original Struts subprojects, along with the new kids on the block, Flow, Scripting, and Shale. > Everyone seems to want to go off and create something entirely new when > I haven't seen a single good, concrete reason why Struts as it exists > today can't be evolved. Why? It *is* being evolved. It's just that evolution takes time. Personally, I still fully intend to walk down the Struts Classic Roadmap that we posted over a year ago. We're just now hitting the first milestone: subprojects. We hit this one, and we'll hit the others too. * http://struts.apache.org/roadmap.html Meanwhile, exploring alternatives like Ti can be good for Struts Classic too. Like as not, there will be techniques used in Ti that we can retrofit to Struts Classic. And, perhaps, one day, they might even evolve into the same product. Or not. At this point, Ti is still hypotethical. > > Many of the things that people claim to want in a modern framework I > have either myself done or seen done with the current Struts codebase. > Things like components that remember and render their own state ala JSF, > a simple managed bean facility (IoC), built-in AJAX support, something > akin to a prerender facility, the work of Michael Jouravlev, all of > these things have been done in Struts, so clearly it is not a case of > Struts not being expandable or "fixable". Why is there so much seeming > resistance to doing this I wonder? It's not resistance, it's as you say: If we want to, we can already do all of this now in our own applications. I expect that many of us are. But, going the extra yard and making what we do for ourselves available to everyone is a lot of work. We're doing the work, but it's on a time available basis, and most of us have very little time available. Unlike some open source projects, we don't have any committers who are paid to work on Struts during company time. Because committers tend to have busy professional lives, we try to bring on new committers whenever we can. Last month, we brought on Wendy Smoak, who has been a godsend. With help from James, She's propelled the Mavenized web sites forward, and we can see the light at the end of the tunnel. Meanwhlile, after adding the "extends" feature, our other new hand, Hubert, cleaned up the stale deprecations, so we can continue to steadily evolve the codebase. Now, it's left to me to finish refactoring the documentation, and push Struts Classic 1.3.0 out the door. It won't be a final release, but it will tap the keg. Once we have a 1.3.0 distribution out for review, I plan to review the 22 enhancement tickets with patches, and apply as many as we can. If someone wanted to preview those patches, and post a summary to dev@, that would be helpful. There are prefab bugzilla query links on the RoadMap page. * http://struts.apache.org/roadmap.html#Bugzilla There's a wiki page already setup for 1.3.1, and we can start making notes on what to do about these other outstanding contributions. * http://wiki.apache.org/struts/StrutsClassicRelease131 -Ted. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
