On 8/25/05, Paul Benedict <[EMAIL PROTECTED]> wrote: > The subject line asks it all. Is it true?
The original subject line, no. The new line, yes. Externally, Struts is evolving from a monolithic package into a set of subprojects, with their own release cycles. Internally, Struts is evolving from a framework with a lockstep request gauntlet, to a framework toolkit, that you can adapt and extend anyway you like. Struts does move more slowly than some other projects. Always have, probably always will. But, we tend to attract pragmatic committers with busy careers, and the volunteer hours are few and far between. In five years, we've yet to have anyone work on Struts fulltime. :( > I hope we see a version 1.2.8 and a 1.3 soon, but I am > sorry to see all the innovation going into Spring > (YEAH!) and Shale (YAWN!), with no one really wanting > to continue growing the classic framework. A lot of the growth has been outside of the project. For example, Hubert's very cool FormDef extension that manufactures DynaForms from POJO's. Frank's AjaxTags. Michael's Struts Dialog extension. * https://formdef.dev.java.net/ * http://struts.sourceforge.net/ajaxtags/index.html * http://struts.sourceforge.net/strutsdialogs/ In the early days, we were careful to chronicle all of the Struts happenings and extensions on the website, but after awhile, there just got to be too much to report. We probably need a newsletter or something to help keep everyone abreast of new developments, and to help summarize the coolest tools. > Is it viable to evolve Struts Classic into Shale, and > mix into the Shale source support for good old Struts? > I say it sounds like a good idea to me.... but I hope > there are better ideas than mine, or we'd all be in > trouble ;-) Personally, I think the underlying problem is that we need more support on the business side of things, so that developers do not become so dependant on the presentation framework. Most of us are still developing "with" Struts, rather than "into" Struts. In my own work, we're having great success using Spring and the Commons Chain of Responsibility as the basis of a business layer framework. Once Struts 1.3.x ships, I'd like to publish more "best practices" applications that demonstration how to minimize dependencies on the presentation layer frameworks. This way, when the next big thing comes along (I doubt that JSF is the end of the line), we won't have to go through this all over again. > With that said, this is my opinion based on > observation of the amazing industry progression in the > MVC area. I hope the Struts committers aren't burnt > out. I love Struts which is why I ask this tough > question. I hope I get some good news and be told I am > wrong :) At the ASF, we expect committers to come and go, and so we make everything a team effort. As committers drift away, and new volunteers step up to take their place. For example, scope the very excellent work our latest committer, Wendy Smoaks, has been doing for the web site. * http://svn.apache.org/builds/struts/maven/trunk/site-test/ We hope that by making Struts a collection of focussed subprojects, instead of a monolithic distribution, we can avoid some of the gridlock that afflicts mature projects. And, happily, this approach also makes room for the new kids on the block, like Shale and Ti <https://www.twdata.org/projects/struts-ti>. HTH, Ted. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
