On 9/9/05, Murray Collingwood <[EMAIL PROTECTED]> wrote: > I'm just a humble Struts user (and relatively new), and I don't claim to > speak for the > group as a whole. > > I have read through Donald Brown's presentation (Struts 1.3 and beyond) and I > get the > feeling that the goal posts just don't stop moving. > > The time I have spent learning and creating a Struts application should be an > investment in my future development, not a stepping stone to a whole new set > of > technologies that will continue to slow my productivity (through on-going > training). > > Who, and this is my question, who makes the decision whether a technology is > going to > be good for the greater community? Who asks the questions "Do we need it?", > "Will > the technology provide significantly greater returns than training costs?", > "Will the > technology last long enough to deliver those returns?"
Open source projects like Apache Struts are *not* designed to be "steering committees" that make these type of decisions for the "greater good". We are simply a group of engineers, just like you, who are trying to ship our own products. But, instead of keeping our work behind closed doors, we try to share what we do with other engineers. Believe it or not, we're not trying to sell anyone anything. If people want to use an Apache Struts product, and contribute to the project by helping out on the list and with the coding, that's great. But, we're not here to garner market share. We're here to foster a community of volunteer developers that can collaborate on creating the software they themselves want to use in their own projects. We're not trying to save the world, we're trying to ship our own next release. > Who is it that has decided we need to keep extending the Struts framework > without > considering the developers' need for better problem identification and > documentation of > the existing Struts system. This list gets so many emails of people > struggling with > existing technology: Dynaforms, Validation, Iteration, Cookies, Flow control, > and the > number of different versions of everything "out there" that we need to know > about in > order to work with this system. > > Who answers the question, "Why aren't we getting better error checking / > debugging > facilities for Struts?" Unpaid volunteers answer that question, and every other question, by donating their own time and energy to the project. Sometimes, individual businesses help answer those questions by letting employeers work on the project during company time. Tthe "Struts PMC" does *not* answer that question, because nobody works for the PMC. We are all unpaid volunteers, each answering that question in our own way, in what little time we have available. The PMC does decide if a contribution becomes part of a Apache Struts distribution, but, first, an unpaid volunteer has to create a contribution for the PMC to review. To answer the explicit question, Struts does not have better error checking because no one has volunteered the time and energy to make that happen. > It would be amiss of me to say Struts alone is responsible here, we should > include > Tomcat, MySQL, Connector/J, JSP, Java. And I'm not saying everybody is doing > a > terrible job, just asking whether we need to refocus our development efforts. > > I'm not a fan of Microsoft but at least they have somebody that makes those > decisions > and they appear to be developing their technology for productivity. They have > documentation. They have tutorials. They have backward compatibility. And, > have Microsoft has these things because Microsoft pays for them. And, as to J2EE, Sun also has these things, because Sun pays for them. The Apache Software Foundation, like most open source organizations, has no paid staff. The ASF can't "decide" how unpaid volunteers spend their free time. Of course, Struts Classic does provide backward compatibility because we want our own applications to enjoy backward compatability between releases. Like most Apache projects, we are very careful to put features through a strict deprecate/release/remove cycle. Not because it makes for a nice bullet on marketing collateral, but because evolutionary compatability is a feature we want for ourselves. > you noticed how many websites are using .NET technology! The number seems to > growing much faster than J2EE or JEE. Well, let's do Struts for .NET, then. Or PHP. Or Ruby (if Rails is not to your liking). As an engineer, I don't much care what technology my clients or employers choose. The engineering skills that matter transfer. Platform specifics are ephemeral details that we will always have to relearn, it's just a matter of when. Struts is an ASF project. It is not our mission to support a particular technology. We are here to foster communities that build software using whatever technologies the volunteers choose. > > When I was looking for an ISP to host my Struts application I found many more > companies providing Microsoft servers with .NET than Unix/Linux servers with > the > necessary version of Tomcat or JBoss. > > If I were to write a web product to be sold and run inhouse, I would probably > develop it > using Microsoft technology, it's just so much easier to say, "requires IIS 6+ > and > SQLserver 2005+" and know that it will work. If you had to ship your product > how many > technologies with specific versions would you have to list? > > Is Struts in danger of becoming just an academic exercise? Hmmm, probably not. Apache Struts developers are not academics, they are working stiffs just like you. We eat our own dog food, and use Struts on our own projects. Don Brown is working on Ti because Don Brown wants to use Ti in his own projects someday. >If Struts is going to be > productive then we need to see: > * more documentation (and I'm not talking about the API, I'm sick of trying > to read the > API and guess the usage of the taglib functions) plus tutorials, online > training etc, > * more tools for building our applications (I know there are some but I'm > on NetBeans > and it appears to be lagging behind, Eclipse and Exadel I found to be too > inflexible), > * more error checking of the configuration files and better error messages > indicating > what the real problem is, maybe even warnings before the program runs, > * more debugging utilities (spying on the http conversations and being able > to > examine the contents of our beans), > * more backward compatibility so that I don't have to spend hours upgrading > my app > when my server updates or I move to a new server, > * more stability in the platform we choose (with reference to the recent > Tomcat bugs > that were brought to the attention of this list). > > If I were asked to vote it would probably be a conservative vote to > consolidate our > current technologies with better tools and a better product. We ask people to vote everyday. Not by raising their virtual hands, but by doing the actual work. * http://struts.apache.org/faqs/helping.html As to J2EE, Sun did "vote" to "consolidate our current technologies with better tools and a better product", and they named the product "JavaServer Faces". If volunteers want to further Sun's "vote", we invite them to help out with Struts Shale. If not, a lot of people are still working on Struts Classic, and some are starting to look at Struts Ti. Sometimes, we hear about people "voting with their feet". Here, we invite people to vote with their hands, by collaborating on code and documentation. It's not up to anyone else. It's up to everyone who volunteers. Here, the only decisions that matter are patches and commits, because without commits, nothing can change. > Okay, there, I said it. It's out of my system and open for discussion. Discussion is good. Stepping up to the plate and making a difference is better. > Kind regards > mc --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
