Don Brown wrote:
Let's be honest - there isn't anything that Struts 1 does that Struts 2 doesn't do and doesn't do better.
This may or may not be true *NOW*, but you may have missed the point: Paul, and Michael at least, have for a long time now been saying they have a lot of ideas for Struts 1 and want to continue developing it, not merely support it as a legacy framework. At some point, s1 may indeed have features that s2 doesn't, and may do some things better, even ignoring the fact that these statements are largely matters of opinion either way. If this evolution isn't going to be allowed, either implicitly or explicitly, then let's hear the words "s1 is dead, long live s2" in a VERY OFFICIAL WAY, and be done with the discussion once and for all. We've heard just the opposite in the past, and I suspect that's what has kept Paul and others going. I don't presume to speak for Paul or anyone else, but I know if I was in *their* shoes, I'd want to know if I was wasting my time trying to do things to make s1 better or not. If I was going to face resistance on anything I tried to do, in their shoes, I want to know that sooner rather than later.
> From a solely framework developer
standpoint, Struts 1 needs to be retired.
WHY?!? If *you* want to retire it from *your* work and where you place *your* efforts, no problem. If anyone else has a desire to keep s1 alive and evolving, do you still think it needs to be retired? If your sole reason is because you don't want to have to keep maintaining a compatibility package in s2, I can certainly see where the desire comes from then. And I can even understand it from a PMC perspective to a degree. But if there is desire to evolve it, and if real work happens to drive that evolution, what good reason could there be for retiring it?
> However, in the real world,
there are thousands, if not more, apps running Struts 1. Most are fine the way they are, and a team supporting Struts 1 is a great thing for them. Heck, I have a few apps that fall into that category, and for that reason, I'm personally dedicated to fixing occasional bugs and security issues.
Right, but I think we're talking about two different things, aren't we? I think everyone understands that s1 will be supported for some time yet, but this is talking about allowing it to continue to grow, which is NOT the same as supporting it. We've heard in the past that there's no reason that can't happen, and Paul here says he has some things he wants to commit. I think the fair question to ask is whether he's going to face resistance doing so or not. Again, I don't speak for him, I only know what questions I'd be asking in his place.
But there will be some teams that will want to migrate code and developer knowledge to a more capable framework.
Ugh, these kinds of statements grind my gears (sorry, just watched the Family Guy movie, I suspect I'll be using that phrase for a while!). "a more capable framework" is such a imprecise statement. I have little doubt that s2 has a longer feature list, but does that equate to "more capable"? Not to everyone. For some, having a known quantity makes it more capable. Having simpler code (which is a matter of opinion I grant you) makes it more capable. Any number of measures may lead someone to conclude that s1 is more "capable" than s2. Just being newer may count for some, but I suspect not for most.
> For those folks, I
want to make that transition as easy as possible, and I think as a Struts community, we owe it to our users to support that process 100% and not just say, "We've moved on to the next shiny thing; good luck with those old apps!"
Certainly, that's a noble goal, I for one applaud you and anyone else striving to meet that goal and thank you in advance!
I think it is great that you and I are committed to supporting Struts 1, but with the amount of existing apps built on it, from a development standpoint, it won't be going anywhere fast, anytime soon.
But that's where, with all due respect Don, I think you are mistaken. If Paul and Michael and whoever else have ideas and want to get to committing new features and adding bells and whistles to s1, it absolutely could be going somewhere fast very soon. Only time will tell if that comes to pass obviously, talk is cheap, yada yada... but to declare it's not going to happen before they try seems to me not very "community-friendly".
As long as backwards-compatibility is taken into account, which I think was what you were getting at, then I don't see any reason s1 can't evolve quickly and even drastically, and why it can't, in principal at least, be "better" than s2 in some ways for some people, and therefore I don't see any reason why it should retired, or why it shouldn't be allowed to develop separately.
I do however understand your concern about going back to the "umbrella" days. If you recall, I screamed as loudly about that situation as anyone for a while. If that concern is shared by all, then I think the only fair thing to do is truly clarify s1's status: it is in fact legacy, and will *not* be allowed to evolve in any significant way on its own. In my mind, this is either stated as the official opinion, or you necessarily go back to the umbrella days to some extent, because some people apparently want to continue evolving s1, and they should if that is going to be allowed to happen or not. I'd want to know if I was in their place.
Don
Frank -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM/Yahoo: fzammetti MSN: [EMAIL PROTECTED] Author of "Practical Ajax Projects With Java Technology" (2006, Apress, ISBN 1-59059-695-1) Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
