Re: [action][Proposal] Architecture plan for Struts Action 2.0
Jason Carreira wrote: I have a couple of comments to make about this. First of all, presumably the whole motivation of this merger is that you could unite your energies on a common framework. If there is still ongoing work on 2 different frameworks, it kind of belies the whole point of the merger, doesn't it? Now, my understanding of the point that Michael Jouravlev was making is that, once you label something as version n+1 of something, you are basically putting out the message that version n is superseded. Typically, verseion n+1 of a product supersedes version n. I may be an excessively simple-minded guy, but if I hit a website and can download FooBar version 1, or FooBar version 2, I guess I'll go with version 2. I will also just assume that all new development is on version 2, not version 1. What would a casual observer make of this? You merge with a competing framework in order to combine your efforts (i.e. not disperse your efforts on 2 different products as before) and you label Webwork as Struts Action 2 when the existing product is version 1. I put it to you that, on the basis of this, nobody with common sense would count on any further development of Struts 1.x taking place. People will just naturally draw the conclusion that Struts 1.x development is being abandoned. If it was not your intent for people to think that, then you chose a very strange product naming strategy. Now, even if, contrary to all outward appearances, this conclusion is wrong, and you guys really do intend to further develop Struts 1.x, how much credibility do you have on this as things stand? Throughout most of the past 4 years, Struts 1.x was the only thing called Struts and was presumably the only real focus of development of Struts committers. However, development stagnated. To tell people that there is going to be any significant development on that codebase now, when it is competing for attention with another codebase (labelled version 2 of same (!)) is asking people to believe quite a bit. But in any case, if whatever project management practices that were followed over the last few years continue to be followed without considering any changes at all, why should a rational person expect results any different than what there has been over the past few years? This would be a valid question IMO even if there was no merger with Webwork and no Shale. If you continue with the exact same approach, which has yielded rather poor results, and besides that, you don't bring in new people to work on Struts 1.x, why should one expect anything much to come out of it? My sense of things is that you should either just forthrightly tell people that Struts 1.x development is being abandoned. Or, if it isn't, you should immediately offer to bring in people who are interested in working on it. Obviously Frank Zammetti is interested. I suspect that Phil Zoio would be interested. Probably other people too. But as things are, the contradictory message you are emitting just seems outrageous. To prevent people who are able and willing to work on Struts 1.x from getting actively involved, and all the while emit confused messages claiming that Struts 1.x is not really being abandoned, surely this is a bit much for even people around here to swallow, isn't it? Jonathan Revusky -- lead developer, FreeMarker project, http://freemarker.org/ This is exactly like the split we had a few years ago when Patrick and I decided to start from scratch with WebWork 2. Jason, I think to say exactly like is really pushing things. I shall point out two very fundamental differences between the two situations: The first is that when you and Patrick decided to start a Webwork 2 -- with, I presume, a new architecture and so on -- this was a situation where you were the ones willing to roll up your sleeves and do the heavy lifting and make things happen. SAF2 involves the existing Struts commmitters, who failed to maintain any development momentum on their product, relabelling *your* work on WW as the next version of Struts. That's kinda different, isn't it? Now, I don't know the situation in any detail that you are describing with Webwork (you have the advantage on me there) but I would say that, sure, there may well have been people in the WW community with reservations about the direction that you and Patrick were taking things with WW 2. BUT... the fact remains that you were the ones willing to do the heavy lifting, and, in a sensibly structured environment, the people willing to roll up their sleeves and do the work are the ones who determine the future direction of a project. (They could well be taking the project in the wrong direction, but they're the ones who are willing to do the work, so they make the decisions. It really can't work any other way IMO.) The other significant difference is that the Webwork situation you allude to does not really present the same
Re: [action][Proposal] Architecture plan for Struts Action 2.0
Ted Husted wrote: On 5/5/06, Michael Jouravlev [EMAIL PROTECTED] wrote: The current versioning/naming system will force them, because it does not make distinction between Classic and WebWork. Most users and/or their managers know that higher version number means newer and better product. Which is why I preferred Classic name for 1.x codebase. I think that before 2.0 and 1.3 are released, it is still possible to reconsider the names. That is, if 1.3 is still considered worth working on. Evidentally, Don, Wendy, Martin, James, and I all feel that 1.3 is a worthwhile endeavor, since we all voted to support the Struts Action 1.3.2 beta release. A lot of work went into 1.3.x, and much of it happened long after 2.0 was announced. I have a couple of comments to make about this. First of all, presumably the whole motivation of this merger is that you could unite your energies on a common framework. If there is still ongoing work on 2 different frameworks, it kind of belies the whole point of the merger, doesn't it? Now, my understanding of the point that Michael Jouravlev was making is that, once you label something as version n+1 of something, you are basically putting out the message that version n is superseded. Typically, verseion n+1 of a product supersedes version n. I may be an excessively simple-minded guy, but if I hit a website and can download FooBar version 1, or FooBar version 2, I guess I'll go with version 2. I will also just assume that all new development is on version 2, not version 1. What would a casual observer make of this? You merge with a competing framework in order to combine your efforts (i.e. not disperse your efforts on 2 different products as before) and you label Webwork as Struts Action 2 when the existing product is version 1. I put it to you that, on the basis of this, nobody with common sense would count on any further development of Struts 1.x taking place. People will just naturally draw the conclusion that Struts 1.x development is being abandoned. If it was not your intent for people to think that, then you chose a very strange product naming strategy. Now, even if, contrary to all outward appearances, this conclusion is wrong, and you guys really do intend to further develop Struts 1.x, how much credibility do you have on this as things stand? Throughout most of the past 4 years, Struts 1.x was the only thing called Struts and was presumably the only real focus of development of Struts committers. However, development stagnated. To tell people that there is going to be any significant development on that codebase now, when it is competing for attention with another codebase (labelled version 2 of same (!)) is asking people to believe quite a bit. But in any case, if whatever project management practices that were followed over the last few years continue to be followed without considering any changes at all, why should a rational person expect results any different than what there has been over the past few years? This would be a valid question IMO even if there was no merger with Webwork and no Shale. If you continue with the exact same approach, which has yielded rather poor results, and besides that, you don't bring in new people to work on Struts 1.x, why should one expect anything much to come out of it? My sense of things is that you should either just forthrightly tell people that Struts 1.x development is being abandoned. Or, if it isn't, you should immediately offer to bring in people who are interested in working on it. Obviously Frank Zammetti is interested. I suspect that Phil Zoio would be interested. Probably other people too. But as things are, the contradictory message you are emitting just seems outrageous. To prevent people who are able and willing to work on Struts 1.x from getting actively involved, and all the while emit confused messages claiming that Struts 1.x is not really being abandoned, surely this is a bit much for even people around here to swallow, isn't it? Jonathan Revusky -- lead developer, FreeMarker project, http://freemarker.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action][Proposal] Architecture plan for Struts Action 2.0
Let's not exaggerate the impact of the API on user code though... Users record validation errors a little differently; you should be able to port existing WW2 code pretty easily with some clever refactorings (which we will document when the time comes). And we're trying to simplify custom interceptor and result implementations. How many custom interceptors and results does a typical user implement? Not many. The new API should be simpler, cleaner, better separated from the implementation, more intuitive, and better organized. If you understand WW2, you'll have no problem understanding the new API. If you haven't learned WW2 yet, it will be easier to learn the new API than WW2. One thing to remember about the WebWork community is that we're generally much more comfortable looking for the hooks into the framework and exploiting them to make our app code simpler and more powerful. Interceptors, custom validators, even custom object factories and ActionInvocation / ActionProxy implementations are not that uncommon. I still don't understand the (too many) roles that the Request object plays in the new API, but all of those hooks that people get into as their projects start to grow are tied to the old APIs. I'll repeat that, for me, it took a couple of weeks of instability to jump from the 2.1.x codebase to 2.2 because we did some big refactorings in 2.2. That was mostly just details compared to the impact API changes would have. Keep that in mind as we think about API changes. I'm all for changes that make things better, but not so much for aesthetics. - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=29563messageID=57925#57925 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action][Proposal] Architecture plan for Struts Action 2.0
I have a couple of comments to make about this. First of all, presumably the whole motivation of this merger is that you could unite your energies on a common framework. If there is still ongoing work on 2 different frameworks, it kind of belies the whole point of the merger, doesn't it? Now, my understanding of the point that Michael Jouravlev was making is that, once you label something as version n+1 of something, you are basically putting out the message that version n is superseded. Typically, verseion n+1 of a product supersedes version n. I may be an excessively simple-minded guy, but if I hit a website and can download FooBar version 1, or FooBar version 2, I guess I'll go with version 2. I will also just assume that all new development is on version 2, not version 1. What would a casual observer make of this? You merge with a competing framework in order to combine your efforts (i.e. not disperse your efforts on 2 different products as before) and you label Webwork as Struts Action 2 when the existing product is version 1. I put it to you that, on the basis of this, nobody with common sense would count on any further development of Struts 1.x taking place. People will just naturally draw the conclusion that Struts 1.x development is being abandoned. If it was not your intent for people to think that, then you chose a very strange product naming strategy. Now, even if, contrary to all outward appearances, this conclusion is wrong, and you guys really do intend to further develop Struts 1.x, how much credibility do you have on this as things stand? Throughout most of the past 4 years, Struts 1.x was the only thing called Struts and was presumably the only real focus of development of Struts committers. However, development stagnated. To tell people that there is going to be any significant development on that codebase now, when it is competing for attention with another codebase (labelled version 2 of same (!)) is asking people to believe quite a bit. But in any case, if whatever project management practices that were followed over the last few years continue to be followed without considering any changes at all, why should a rational person expect results any different than what there has been over the past few years? This would be a valid question IMO even if there was no merger with Webwork and no Shale. If you continue with the exact same approach, which has yielded rather poor results, and besides that, you don't bring in new people to work on Struts 1.x, why should one expect anything much to come out of it? My sense of things is that you should either just forthrightly tell people that Struts 1.x development is being abandoned. Or, if it isn't, you should immediately offer to bring in people who are interested in working on it. Obviously Frank Zammetti is interested. I suspect that Phil Zoio would be interested. Probably other people too. But as things are, the contradictory message you are emitting just seems outrageous. To prevent people who are able and willing to work on Struts 1.x from getting actively involved, and all the while emit confused messages claiming that Struts 1.x is not really being abandoned, surely this is a bit much for even people around here to swallow, isn't it? Jonathan Revusky -- lead developer, FreeMarker project, http://freemarker.org/ This is exactly like the split we had a few years ago when Patrick and I decided to start from scratch with WebWork 2. There still remains a userbase for WebWork 1.x (Jira, as mentioned, is built on 1.x) and some development time is still put into it. Over time, the community shifted to a more and more 2.x focus, but there are still people answering WebWork 1.x questions. Development of 1.x is now mostly bug fixing (although there really aren't very many bugs found anymore) and sometimes backporting features from 2.x. So yes, you can have both, and yes, over time the community shifts to the next version. No one is saying 1.x will be cut off and no more work will be done on it. How much development is done there will depend on what the community needs in terms of bug fixes and new features, possibly some back ported from SAF 2.x to make it easier to migrate to SAF 2.x later. Don't forget that Struts 1.x still has the largest user base of any framework. No one thinks that a ship of that size can be turned on a dime. :-) - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=29563messageID=57927#57927 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action][Proposal] Architecture plan for Struts Action 2.0
On 5/6/06, Bob Lee [EMAIL PROTECTED] wrote: The new API should be simpler, cleaner, better separated from the implementation, more intuitive, and better organized. If you understand WW2, you'll have no problem understanding the new API. If you haven't learned WW2 yet, it will be easier to learn the new API than WW2. All of which seems to imply that the new API might be the equivalent of WW 3. We've always planned to consider signficant API changes for SAF 2.0 Next as Ti Phase 2, but we need to set modest, achievable expectations for SAF 2.0 (aka WW 2.3). The first phase is an evolutionary transition. The second phase is meant to be revolutionary. Of course, without code on the table, it's too soon to say yes, no, or maybe. No matter what anyone plans to do, the implementation has to pass muster. The most anyone here can say is Looks cool, show us the code or Here's the code, how do you like it?. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action][Proposal] Architecture plan for Struts Action 2.0
I am a bit surprised that this was not all pretty well worked out in detail before the merger. Why not first take the time to see what will need to be done and what the result will look like before deciding to do it? That should not be a daunting task. A list of what the result will take and what the result will look like would be worth having before taking a vote on this. To just a make a decision and to start coding blindly before knowing what the parameters of the situation are would be just to return to past throw it against the wall and see what sticks sort of decision making. The continuing introduction of Ti into these conversations is confusing to me. I am not sure what Ted means by that. I know Ted and I know it is an agenda for sure, but I don't know what that agenda is. I also don't see the arguments (reasons) for evolution now revolution later decisions. Are there any that have been gathered, arranged, collated, etc? This all seems a bit out of control and not well-planned. These sorts of discussion, by the way, have nothing to do with architecture. On 5/7/06, Ted Husted [EMAIL PROTECTED] wrote: On 5/6/06, Bob Lee [EMAIL PROTECTED] wrote: The new API should be simpler, cleaner, better separated from the implementation, more intuitive, and better organized. If you understand WW2, you'll have no problem understanding the new API. If you haven't learned WW2 yet, it will be easier to learn the new API than WW2. All of which seems to imply that the new API might be the equivalent of WW 3. We've always planned to consider signficant API changes for SAF 2.0 Next as Ti Phase 2, but we need to set modest, achievable expectations for SAF 2.0 (aka WW 2.3). The first phase is an evolutionary transition. The second phase is meant to be revolutionary. Of course, without code on the table, it's too soon to say yes, no, or maybe. No matter what anyone plans to do, the implementation has to pass muster. The most anyone here can say is Looks cool, show us the code or Here's the code, how do you like it?. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- You can lead a horse to water but you cannot make it float on its back. ~Dakota Jack~
Re: [action][Proposal] Architecture plan for Struts Action 2.0
Don't worry, David. We're just talking about cleaning up the API and making your code a little cleaner. It's fundamentally the same framework with the same philosophies. Bob On 5/5/06, David Evans [EMAIL PROTECTED] wrote: I am a struts user who has recently began programming in webwork, to get a head start for action 2. Having just spent many hours researching, reading about and experimenting with webwork, I personally hope that you start with a version of action 2 that resembles webwork pretty closely. I wonder how many other people are in my shoes. If ease of migration is a major concern for the project, maybe a survey on struts-user would be useful, something like: Regarding Struts Action 2 and Webwork do you... [ ] plan to keep using struts action 1 for new apps [ ] plan to use struts 2 for new apps when released [ ] plan to use webwork for new apps til struts 2 is released I think that having the current webwork user base as a resource that may help the much larger struts users base to migrate is a consideration that should be taken in your deliberations as well, because if struts action 2 is new everyone, that may make adoption slower. Dave On Fri, 2006-05-05 at 13:04 -0700, Don Brown wrote: Ok, let's just make this an official proposal and focus all of this discussion: I propose that the architecture plan for Struts Action 2.0 includes the following: 1. A re-design of the API to simplify the framework the users see 2. Backwards-compatibility support for WebWork 2 and Struts 1.x applications 3. Continue to use XWork for a) compatibility reasons and b) the core implementation of the new API 4. A target GA release by August This means for current WebWork 2 users: 1. WebWork continues to apply bug fixes for the WebWork 2.1.x and 2.2.x branches 2. Migration to Struts Action 2.0 should take hours, not days, weeks, but probably not minutes. For Struts Action 1 users: 1. Struts Action 1.x will continue to be developed actively 2. Migration to Struts Action 2.0 should take days, using available migration tools and compatibility libraries I think this proposal is a good middle ground between folks that want WebWork 2.2 with just package renaming, and others that want a completely new framework. Please register your comments and if necessary, I'll call a vote so we can decide this once and for all, and get back to coding. Don - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action][Proposal] Architecture plan for Struts Action 2.0
Don't worry, David. We're just talking about cleaning up the API and making your code a little cleaner. It's fundamentally the same framework with the same philosophies. Bob Maybe the same philosophies, but the API you laid out is very different for users of the framework... - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=29563messageID=57556#57556 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action][Proposal] Architecture plan for Struts Action 2.0
On 5/6/06, Jason Carreira [EMAIL PROTECTED] wrote: Maybe the same philosophies, but the API you laid out is very different for users of the framework... Let's not exaggerate the impact of the API on user code though... Users record validation errors a little differently; you should be able to port existing WW2 code pretty easily with some clever refactorings (which we will document when the time comes). And we're trying to simplify custom interceptor and result implementations. How many custom interceptors and results does a typical user implement? Not many. The new API should be simpler, cleaner, better separated from the implementation, more intuitive, and better organized. If you understand WW2, you'll have no problem understanding the new API. If you haven't learned WW2 yet, it will be easier to learn the new API than WW2. Bob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action][Proposal] Architecture plan for Struts Action 2.0
On 5/5/06, Don Brown [EMAIL PROTECTED] wrote: Ok, let's just make this an official proposal and focus all of this discussion: I propose that the architecture plan for Struts Action 2.0 includes the following: 1. A re-design of the API to simplify the framework the users see 2. Backwards-compatibility support for WebWork 2 and Struts 1.x applications 3. Continue to use XWork for a) compatibility reasons and b) the core implementation of the new API 4. A target GA release by August This means for current WebWork 2 users: 1. WebWork continues to apply bug fixes for the WebWork 2.1.x and 2.2.x branches 2. Migration to Struts Action 2.0 should take hours, not days, weeks, but probably not minutes. For Struts Action 1 users: 1. Struts Action 1.x will continue to be developed actively 2. Migration to Struts Action 2.0 should take days, using available migration tools and compatibility libraries I think this proposal is a good middle ground between folks that want WebWork 2.2 with just package renaming, and others that want a completely new framework. Please register your comments and if necessary, I'll call a vote so we can decide this once and for all, and get back to coding. Don SAF1 could have future if migration to SAF2 were impossible or too complicated. But according to your plan, migration from SAF1 to SAF2 should take days. What is the point of keeping Action 1.x to be developed actively? I am not objecting, I am just asking. Trying to understand where I am ;-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action][Proposal] Architecture plan for Struts Action 2.0
Michael Jouravlev wrote: SAF1 could have future if migration to SAF2 were impossible or too complicated. But according to your plan, migration from SAF1 to SAF2 should take days. What is the point of keeping Action 1.x to be developed actively? I am not objecting, I am just asking. Trying to understand where I am ;-) It is more a question of committer time and energy. There are committers that want to only work with Action 1, so even if there is a smooth upgrade path, Action 1 will continue to be developed. Now, there is a difference between actively developed and simply supported. The Struts PMC is totally committed to support Action 1, meaning bug fixes, security fixes, etc. Whether Action 1 sees more releases with fancy new features is up to those that want to do the work. Personally, I'll be supporting Action 1, but actively developing 2. If Action 1 keeps going, I might backport some things to it, however, to make the conceptual transition for the developer easier to 2. Don - 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]
Re: [action][Proposal] Architecture plan for Struts Action 2.0
Just as some people continue to use WebWork 1.xx (JIRA) I imagine people will continue to use SAF1 regardless of how easy the migration path is. I always assume it would take a day or two to convert existing WW code to SAF2 so at the end of the day just picking a direction is progress. :) Cheers, Eric On 5/5/06, Michael Jouravlev [EMAIL PROTECTED] wrote: On 5/5/06, Don Brown [EMAIL PROTECTED] wrote: Ok, let's just make this an official proposal and focus all of this discussion: I propose that the architecture plan for Struts Action 2.0 includes the following: 1. A re-design of the API to simplify the framework the users see 2. Backwards-compatibility support for WebWork 2 and Struts 1.x applications 3. Continue to use XWork for a) compatibility reasons and b) the core implementation of the new API 4. A target GA release by August This means for current WebWork 2 users: 1. WebWork continues to apply bug fixes for the WebWork 2.1.x and 2.2.x branches 2. Migration to Struts Action 2.0 should take hours, not days, weeks, but probably not minutes. For Struts Action 1 users: 1. Struts Action 1.x will continue to be developed actively 2. Migration to Struts Action 2.0 should take days, using available migration tools and compatibility libraries I think this proposal is a good middle ground between folks that want WebWork 2.2 with just package renaming, and others that want a completely new framework. Please register your comments and if necessary, I'll call a vote so we can decide this once and for all, and get back to coding. Don SAF1 could have future if migration to SAF2 were impossible or too complicated. But according to your plan, migration from SAF1 to SAF2 should take days. What is the point of keeping Action 1.x to be developed actively? I am not objecting, I am just asking. Trying to understand where I am ;-) - 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]
Re: [action][Proposal] Architecture plan for Struts Action 2.0
I'm OK with this, from an end user perspective certainly, and from a (sort of I guess) framework developer as well. However, you raise an interesting point in my mind... Struts Action 1.x will continue to be developed actively Ok... I personally like that. However, why wouldn't it also be said that Webwork 2.x.x will continue to be developed actively too? You do mention continuing to apply patches, but that's different. The reason I ask that question is this... There are a lot of API changes being bandied about. Some are minor, some possibly major. If ever there was a time to get it right, so to speak, and in the process break backwards-compatibility, I would think now is the time. Especially when the proposal includes active development of an old branch, so no one is left behind, why not say the same for Webwork, and then drop the idea of compatibility for SAF2 entirely? Obviously there has to be people in the Webwork community willing to do that too. I think that would focus resources first of all... those that are working on SAF2 can do so without concern for SAF1 or even Webwork 2.x.x compatibility. Secondly, it would allow all the revolutionary ideas to be included without issue. Now, you might argue that keeping compatibility brings the existing communities along, and I don't disagree. But, isn't that negated by making it official policy, as it were, to continue developing the older branches as well? The community isn't being left behind in that case. You might also argue that keeping compatibility, to the extent that it tends to limit the degree of change to the API, might act as something of a governor to the inevitable scope creep, and thereby keep things more or less on schedule. Again, I wouldn't disagree, but I think there are other ways to do that which still allow the big changes to happen. The only down-side I can see is if no one wants to continue work on Webwork 2.x.x. Then that community suffers. Any thoughts? Frank Don Brown wrote: Ok, let's just make this an official proposal and focus all of this discussion: I propose that the architecture plan for Struts Action 2.0 includes the following: 1. A re-design of the API to simplify the framework the users see 2. Backwards-compatibility support for WebWork 2 and Struts 1.x applications 3. Continue to use XWork for a) compatibility reasons and b) the core implementation of the new API 4. A target GA release by August This means for current WebWork 2 users: 1. WebWork continues to apply bug fixes for the WebWork 2.1.x and 2.2.x branches 2. Migration to Struts Action 2.0 should take hours, not days, weeks, but probably not minutes. For Struts Action 1 users: 1. Struts Action 1.x will continue to be developed actively 2. Migration to Struts Action 2.0 should take days, using available migration tools and compatibility libraries I think this proposal is a good middle ground between folks that want WebWork 2.2 with just package renaming, and others that want a completely new framework. Please register your comments and if necessary, I'll call a vote so we can decide this once and for all, and get back to coding. Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM: fzammetti Yahoo: fzammetti MSN: [EMAIL PROTECTED] 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]
Re: [action][Proposal] Architecture plan for Struts Action 2.0
Don, Thanks for drawing up a proposal. I suggest allow ample discussion time before this is called to a vote. Where XWork is in this proposal is a little vague. Would this proposal break the traditional division of roles between XWork and Webwork (Where SAF 2 is where webwork was)? If so, how so? Is this proposing that there be an adapter layer in SAF 2 to access XWork APIs? Would we be looking to push changes into XWork? Thanks, Gabe - Original Message From: Don Brown [EMAIL PROTECTED] To: Struts Developers List dev@struts.apache.org Sent: Friday, May 5, 2006 4:04:35 PM Subject: [action][Proposal] Architecture plan for Struts Action 2.0 Ok, let's just make this an official proposal and focus all of this discussion: I propose that the architecture plan for Struts Action 2.0 includes the following: 1. A re-design of the API to simplify the framework the users see 2. Backwards-compatibility support for WebWork 2 and Struts 1.x applications 3. Continue to use XWork for a) compatibility reasons and b) the core implementation of the new API 4. A target GA release by August This means for current WebWork 2 users: 1. WebWork continues to apply bug fixes for the WebWork 2.1.x and 2.2.x branches 2. Migration to Struts Action 2.0 should take hours, not days, weeks, but probably not minutes. For Struts Action 1 users: 1. Struts Action 1.x will continue to be developed actively 2. Migration to Struts Action 2.0 should take days, using available migration tools and compatibility libraries I think this proposal is a good middle ground between folks that want WebWork 2.2 with just package renaming, and others that want a completely new framework. Please register your comments and if necessary, I'll call a vote so we can decide this once and for all, and get back to coding. Don - 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]
Re: [action][Proposal] Architecture plan for Struts Action 2.0
If the WebWork committers make the decision to continue developing WebWork 2.x, they are entirely free to do so. If Struts Action 1 committers decide to continue developing Action 1, they are also free to do so. However, if WebWork 2 developers decide to stop work and focus completely on Struts Action Framework 2, that is also their decision. The purpose of this merger is not to create yet another framework or kill off competition, but to start collaborating as framework developers for the greater good of the general community. By focusing on who can do what or why can't a project release something, you are missing the point. The point is to collaborate to build a single Action-based framework that combines the talents of the Struts and WebWork teams, and hopefully more. Yes, there will be compromises, and yes, we can't force anyone to do anything, but we are here aren't we, so let's make the most of it. The purpose of this proposal is come to some sort of agreement of where we want to take Struts Action 2, so we can get back to work. Don Frank W. Zammetti wrote: I'm OK with this, from an end user perspective certainly, and from a (sort of I guess) framework developer as well. However, you raise an interesting point in my mind... Struts Action 1.x will continue to be developed actively Ok... I personally like that. However, why wouldn't it also be said that Webwork 2.x.x will continue to be developed actively too? You do mention continuing to apply patches, but that's different. The reason I ask that question is this... There are a lot of API changes being bandied about. Some are minor, some possibly major. If ever there was a time to get it right, so to speak, and in the process break backwards-compatibility, I would think now is the time. Especially when the proposal includes active development of an old branch, so no one is left behind, why not say the same for Webwork, and then drop the idea of compatibility for SAF2 entirely? Obviously there has to be people in the Webwork community willing to do that too. I think that would focus resources first of all... those that are working on SAF2 can do so without concern for SAF1 or even Webwork 2.x.x compatibility. Secondly, it would allow all the revolutionary ideas to be included without issue. Now, you might argue that keeping compatibility brings the existing communities along, and I don't disagree. But, isn't that negated by making it official policy, as it were, to continue developing the older branches as well? The community isn't being left behind in that case. You might also argue that keeping compatibility, to the extent that it tends to limit the degree of change to the API, might act as something of a governor to the inevitable scope creep, and thereby keep things more or less on schedule. Again, I wouldn't disagree, but I think there are other ways to do that which still allow the big changes to happen. The only down-side I can see is if no one wants to continue work on Webwork 2.x.x. Then that community suffers. Any thoughts? Frank Don Brown wrote: Ok, let's just make this an official proposal and focus all of this discussion: I propose that the architecture plan for Struts Action 2.0 includes the following: 1. A re-design of the API to simplify the framework the users see 2. Backwards-compatibility support for WebWork 2 and Struts 1.x applications 3. Continue to use XWork for a) compatibility reasons and b) the core implementation of the new API 4. A target GA release by August This means for current WebWork 2 users: 1. WebWork continues to apply bug fixes for the WebWork 2.1.x and 2.2.x branches 2. Migration to Struts Action 2.0 should take hours, not days, weeks, but probably not minutes. For Struts Action 1 users: 1. Struts Action 1.x will continue to be developed actively 2. Migration to Struts Action 2.0 should take days, using available migration tools and compatibility libraries I think this proposal is a good middle ground between folks that want WebWork 2.2 with just package renaming, and others that want a completely new framework. Please register your comments and if necessary, I'll call a vote so we can decide this once and for all, and get back to coding. Don - 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]
Re: [action][Proposal] Architecture plan for Struts Action 2.0
Gabe wrote: Where XWork is in this proposal is a little vague. Would this proposal break the traditional division of roles between XWork and Webwork (Where SAF 2 is where webwork was)? If so, how so? Is this proposing that there be an adapter layer in SAF 2 to access XWork APIs? Would we be looking to push changes into XWork? XWork would be hidden behind the new API for new projects, but available for older ones or just those that want to continue working with XWork directly. Again, it is too soon to expect fully-fleshed out details, but remember the end goal of simplifying the API to a end developer. That goal will drive any changes. Don Thanks, Gabe - Original Message From: Don Brown [EMAIL PROTECTED] To: Struts Developers List dev@struts.apache.org Sent: Friday, May 5, 2006 4:04:35 PM Subject: [action][Proposal] Architecture plan for Struts Action 2.0 Ok, let's just make this an official proposal and focus all of this discussion: I propose that the architecture plan for Struts Action 2.0 includes the following: 1. A re-design of the API to simplify the framework the users see 2. Backwards-compatibility support for WebWork 2 and Struts 1.x applications 3. Continue to use XWork for a) compatibility reasons and b) the core implementation of the new API 4. A target GA release by August This means for current WebWork 2 users: 1. WebWork continues to apply bug fixes for the WebWork 2.1.x and 2.2.x branches 2. Migration to Struts Action 2.0 should take hours, not days, weeks, but probably not minutes. For Struts Action 1 users: 1. Struts Action 1.x will continue to be developed actively 2. Migration to Struts Action 2.0 should take days, using available migration tools and compatibility libraries I think this proposal is a good middle ground between folks that want WebWork 2.2 with just package renaming, and others that want a completely new framework. Please register your comments and if necessary, I'll call a vote so we can decide this once and for all, and get back to coding. Don - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action][Proposal] Architecture plan for Struts Action 2.0
Don Brown wrote: The purpose of this merger is not to create yet another framework or kill off competition, but to start collaborating as framework developers for the greater good of the general community. By focusing on who can do what or why can't a project release something, you are missing the point. The point is to collaborate to build a single Action-based framework that combines the talents of the Struts and WebWork teams, and hopefully more. But that's precisely my point... isn't the best way to combine the talents to take the cuffs off, so to speak, and not worry about backwards-compatibility? Why should those talents be shackled to that compatibility *IF* the existing frameworks are going to continue to be actively developed? Your proposal explicitly states that SAF1 will do so... if the Webwork folks were to say the same thing, that to me removes the need to keep compatibility (and even if they didn't want to do that, which I agree is completely their choice, is the community big enough to warrant sticking with compatibility?). That's my point. I see it as a way to maximize the outcome of the merger. Yes, there will be compromises, and yes, we can't force anyone to do anything, but we are here aren't we, so let's make the most of it. Again, precisely my point. There are a lot of good ideas being talked about... but many of them either can't be done, or can't be done to their full potential, if backwards-compatibility is still clung to. If the existing branches can continue to develop, then the community is not hurt by breaking compatibility, they are actually HELPED because the merger yields a much greater value in the end, and people will probably want to migrate despite the problems. The purpose of this proposal is come to some sort of agreement of where we want to take Struts Action 2, so we can get back to work. Of course, it'd be foolish for it to have any other purpose :) I'm just raising one way that agreement might be reached sooner than later. I might be wrong, but I'm putting it out there for discussion just the same. Don Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action][Proposal] Architecture plan for Struts Action 2.0
I am all for simplifying the API to the end developer, but I wonder if those changes could be pushed to XWork in the form of an XWork 2.0, with, of course, the Web specific portions being added to SAF 2. I see the reasoning behind creating a layer to hide XWork (everything the user uses is Struts 2), but I believe the logical conclusion of that reasoning is to move XWork as well to Struts rather than adapter layer. I won't elaborate because I have in other threads. ;-) - Original Message From: Don Brown [EMAIL PROTECTED] To: Struts Developers List dev@struts.apache.org Sent: Friday, May 5, 2006 4:36:13 PM Subject: Re: [action][Proposal] Architecture plan for Struts Action 2.0 Gabe wrote: Where XWork is in this proposal is a little vague. Would this proposal break the traditional division of roles between XWork and Webwork (Where SAF 2 is where webwork was)? If so, how so? Is this proposing that there be an adapter layer in SAF 2 to access XWork APIs? Would we be looking to push changes into XWork? XWork would be hidden behind the new API for new projects, but available for older ones or just those that want to continue working with XWork directly. Again, it is too soon to expect fully-fleshed out details, but remember the end goal of simplifying the API to a end developer. That goal will drive any changes. Don Thanks, Gabe - Original Message From: Don Brown [EMAIL PROTECTED] To: Struts Developers List dev@struts.apache.org Sent: Friday, May 5, 2006 4:04:35 PM Subject: [action][Proposal] Architecture plan for Struts Action 2.0 Ok, let's just make this an official proposal and focus all of this discussion: I propose that the architecture plan for Struts Action 2.0 includes the following: 1. A re-design of the API to simplify the framework the users see 2. Backwards-compatibility support for WebWork 2 and Struts 1.x applications 3. Continue to use XWork for a) compatibility reasons and b) the core implementation of the new API 4. A target GA release by August This means for current WebWork 2 users: 1. WebWork continues to apply bug fixes for the WebWork 2.1.x and 2.2.x branches 2. Migration to Struts Action 2.0 should take hours, not days, weeks, but probably not minutes. For Struts Action 1 users: 1. Struts Action 1.x will continue to be developed actively 2. Migration to Struts Action 2.0 should take days, using available migration tools and compatibility libraries I think this proposal is a good middle ground between folks that want WebWork 2.2 with just package renaming, and others that want a completely new framework. Please register your comments and if necessary, I'll call a vote so we can decide this once and for all, and get back to coding. Don - 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] - 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]
Re: [action][Proposal] Architecture plan for Struts Action 2.0
Gabe wrote: I am all for simplifying the API to the end developer, but I wonder if those changes could be pushed to XWork in the form of an XWork 2.0, with, of course, the Web specific portions being added to SAF 2. Agreed, and with my XWork developer hat on, XWork 2.0 will be required to support Java 5 properly, in alignment with the Java 5 target Struts Action 2 decided on. Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action][Proposal] Architecture plan for Struts Action 2.0
This sounds fine to me, Don. I'd suggest annexing this to the original Ti proposal as a clarification. -Ted. On 5/5/06, Don Brown [EMAIL PROTECTED] wrote: Ok, let's just make this an official proposal and focus all of this discussion: I propose that the architecture plan for Struts Action 2.0 includes the following: 1. A re-design of the API to simplify the framework the users see 2. Backwards-compatibility support for WebWork 2 and Struts 1.x applications 3. Continue to use XWork for a) compatibility reasons and b) the core implementation of the new API 4. A target GA release by August This means for current WebWork 2 users: 1. WebWork continues to apply bug fixes for the WebWork 2.1.x and 2.2.x branches 2. Migration to Struts Action 2.0 should take hours, not days, weeks, but probably not minutes. For Struts Action 1 users: 1. Struts Action 1.x will continue to be developed actively 2. Migration to Struts Action 2.0 should take days, using available migration tools and compatibility libraries I think this proposal is a good middle ground between folks that want WebWork 2.2 with just package renaming, and others that want a completely new framework. Please register your comments and if necessary, I'll call a vote so we can decide this once and for all, and get back to coding. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action][Proposal] Architecture plan for Struts Action 2.0
On 5/5/06, Frank W. Zammetti [EMAIL PROTECTED] wrote: But that's precisely my point... isn't the best way to combine the talents to take the cuffs off, so to speak, and not worry about backwards-compatibility? Yes, and this is why the Ti proposal talks about two phases. In the first phase, the projects join forces and create a common codebase. In the second phase, we move on to brave new development. There are people who are eager to get started on Phase 2, which is understandable. There are many great ideas that we can explore. But, I think the core group would like to complete Phase 1 first, and then move on to Phase 2. The Phase 2 planning can continue, and we can even start some whiteboards, but we need do first things first. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action][Proposal] Architecture plan for Struts Action 2.0
On 5/5/06, Frank W. Zammetti [EMAIL PROTECTED] wrote: If the existing branches can continue to develop, then the community is not hurt by breaking compatibility, they are actually HELPED because the merger yields a much greater value in the end, and people will probably want to migrate despite the problems. Friday I am trying to imagine a book title: New features of Struts 1.3, and then another one on the same shelf Struts 2.0: a definitive guide. Something does not feel right... This situation is worse than General Motors product line. Imagine GM 1.3 and GM 2.0 instead of Saab 9-3 and Chevrolet Malibu. Well, Saab is almost dead anyway. With current product names and version numbers, 1.x does not stand a chance (for new projects). I feel like improving 1.x, but I don't think that it will make much sense. Should finish the WW book instead, I guess. /Friday - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action][Proposal] Architecture plan for Struts Action 2.0
Michael Jouravlev wrote: On 5/5/06, Frank W. Zammetti [EMAIL PROTECTED] wrote: If the existing branches can continue to develop, then the community is not hurt by breaking compatibility, they are actually HELPED because the merger yields a much greater value in the end, and people will probably want to migrate despite the problems. Friday I am trying to imagine a book title: New features of Struts 1.3, and then another one on the same shelf Struts 2.0: a definitive guide. Something does not feel right... This situation is worse than General Motors product line. Imagine GM 1.3 and GM 2.0 instead of Saab 9-3 and Chevrolet Malibu. Well, Saab is almost dead anyway. For this reason, they should be separate projects which should be allowed to evolve independently and indefinitely into the future (as long as there are developers - such as yourself, apparently - who are willing to do). There is no reason in my opinion why Struts 1.x should not be allowed to become Struts (Classic) 2.x, 3.x, etc. at some point in the future. It's life cycle should not be cut short by replacement with WW. Insteady, they should be frameworks with parallel existence. Let users decide when (if at all) to make the switch. Don't force it on them. With current product names and version numbers, 1.x does not stand a chance (for new projects). I feel like improving 1.x, but I don't think that it will make much sense. Should finish the WW book instead, I guess. /Friday - 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]
Re: [action][Proposal] Architecture plan for Struts Action 2.0
On 5/5/06, Phil Zoio [EMAIL PROTECTED] wrote: Michael Jouravlev wrote: On 5/5/06, Frank W. Zammetti [EMAIL PROTECTED] wrote: If the existing branches can continue to develop, then the community is not hurt by breaking compatibility, they are actually HELPED because the merger yields a much greater value in the end, and people will probably want to migrate despite the problems. Friday I am trying to imagine a book title: New features of Struts 1.3, and then another one on the same shelf Struts 2.0: a definitive guide. Something does not feel right... This situation is worse than General Motors product line. Imagine GM 1.3 and GM 2.0 instead of Saab 9-3 and Chevrolet Malibu. Well, Saab is almost dead anyway. For this reason, they should be separate projects which should be allowed to evolve independently and indefinitely into the future (as long as there are developers - such as yourself, apparently - who are willing to do). There is no reason in my opinion why Struts 1.x should not be allowed to become Struts (Classic) 2.x, 3.x, etc. at some point in the future. It's life cycle should not be cut short by replacement with WW. Insteady, they should be frameworks with parallel existence. Let users decide when (if at all) to make the switch. Don't force it on them. The current versioning/naming system will force them, because it does not make distinction between Classic and WebWork. Most users and/or their managers know that higher version number means newer and better product. Which is why I preferred Classic name for 1.x codebase. I think that before 2.0 and 1.3 are released, it is still possible to reconsider the names. That is, if 1.3 is still considered worth working on. Sorry for hijaacing the Struts 2.0 thread. But Don mentioned 1.x first ;-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action][Proposal] Architecture plan for Struts Action 2.0
On 5/5/06, Michael Jouravlev [EMAIL PROTECTED] wrote: The current versioning/naming system will force them, because it does not make distinction between Classic and WebWork. Most users and/or their managers know that higher version number means newer and better product. Which is why I preferred Classic name for 1.x codebase. I think that before 2.0 and 1.3 are released, it is still possible to reconsider the names. That is, if 1.3 is still considered worth working on. Evidentally, Don, Wendy, Martin, James, and I all feel that 1.3 is a worthwhile endeavor, since we all voted to support the Struts Action 1.3.2 beta release. A lot of work went into 1.3.x, and much of it happened long after 2.0 was announced. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action][Proposal] Architecture plan for Struts Action 2.0
I am a struts user who has recently began programming in webwork, to get a head start for action 2. Having just spent many hours researching, reading about and experimenting with webwork, I personally hope that you start with a version of action 2 that resembles webwork pretty closely. I wonder how many other people are in my shoes. If ease of migration is a major concern for the project, maybe a survey on struts-user would be useful, something like: Regarding Struts Action 2 and Webwork do you... [ ] plan to keep using struts action 1 for new apps [ ] plan to use struts 2 for new apps when released [ ] plan to use webwork for new apps til struts 2 is released I think that having the current webwork user base as a resource that may help the much larger struts users base to migrate is a consideration that should be taken in your deliberations as well, because if struts action 2 is new everyone, that may make adoption slower. Dave On Fri, 2006-05-05 at 13:04 -0700, Don Brown wrote: Ok, let's just make this an official proposal and focus all of this discussion: I propose that the architecture plan for Struts Action 2.0 includes the following: 1. A re-design of the API to simplify the framework the users see 2. Backwards-compatibility support for WebWork 2 and Struts 1.x applications 3. Continue to use XWork for a) compatibility reasons and b) the core implementation of the new API 4. A target GA release by August This means for current WebWork 2 users: 1. WebWork continues to apply bug fixes for the WebWork 2.1.x and 2.2.x branches 2. Migration to Struts Action 2.0 should take hours, not days, weeks, but probably not minutes. For Struts Action 1 users: 1. Struts Action 1.x will continue to be developed actively 2. Migration to Struts Action 2.0 should take days, using available migration tools and compatibility libraries I think this proposal is a good middle ground between folks that want WebWork 2.2 with just package renaming, and others that want a completely new framework. Please register your comments and if necessary, I'll call a vote so we can decide this once and for all, and get back to coding. Don - 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]
