Re: Status of 1.3.5, 1.x, and loose ends
Hey Paul, I'm interested in seeing Struts 1.x maintained as well and will contribute time to that effort. James On Thu Jun 22 20:22 , Paul Benedict <[EMAIL PROTECTED]> sent: >What is the status of 1.3.5? It sounds like it's almost baked. > > > >By the way, I am volunteering to continue adding features to 1.x. Michael says >he is also. I read today Niall is too. Who else on the team still wishes to add features for this codebase? Just looking to know who is on the "inner team". > > > >PS: Have you locked down Struts bugzilla? I saw someone last week entered a >bug into it (I got a bugzilla mail), when they should have done so in JIRA. > > > >-- Paul > > > > > >- > >How low will we go? Check out Yahoo! Messengers low PC-to-Phone call rates. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Status of 1.3.5, 1.x, and loose ends
On Thu, Jun 22, 2006 at 08:36:47PM -0700, Paul Benedict wrote: > Well... What are the ramifications of removing bugzilla? Can we just > get rid of any bugzilla links we have on our site? Advertise jira. A better solution would be to modify Bugzilla to let users know when a bug has been superceded. See: http://issues.apache.org/jira/browse/INFRA-859 --Jeff > Martin Cooper <[EMAIL PROTECTED]> wrote: On 6/22/06, Paul Benedict > wrote: > > > > What is the status of 1.3.5? It sounds like it's almost baked. > > > > By the way, I am volunteering to continue adding features to 1.x. Michael > > says he is also. I read today Niall is too. Who else on the team still > > wishes to add features for this codebase? Just looking to know who is on the > > "inner team". > > > I just switched employers, starting today, and my new employer is not > currently using Struts. If we do in the future, it's not likely to be 1.x. > That being the case, the likelihood of me putting my own time into 1.x is > somewhat low now. > > PS: Have you locked down Struts bugzilla? I saw someone last week entered a > > bug into it (I got a bugzilla mail), when they should have done so in JIRA. > > > Bugzilla can only be locked down for new bug entry, which has been done. > Unfortunately, there isn't a way to stop people updating existing issues, > which is somewhat annoying. ;-( > > -- > Martin Cooper > > > -- Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Does Struts really need two frameworks? (long)
I am just trying to figure out how all the movement the last few years fits into this supposed picture of reality. How does Shale fit into this? How does WebWorks fit into this? This is mere words without any inkling of the reality of what happens on Struts. On 6/22/06, Ted Husted <[EMAIL PROTECTED]> wrote: On 6/22/06, Michael Jouravlev <[EMAIL PROTECTED]> wrote: > In the meantime I want to make sure that SAF1 will not be simply > removed from source repository just because SAF2 is the official > future. The future belongs to the volunteers willing to do the work. So long as we have volunteers to work on the SAF1 codebase, then the work will continue. Trying to kill a codebase is a marketplace ploy. As an ASF project, our mandate is *not* "conquer the marketplace". Our mandate is to create an environment where a community of volunteers can collaborate on open source software. If the product finds marketplace acceptance, that's icing. But, it is *not* the point of the exercise. -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: Does Struts really need two frameworks? (long)
I see a lot more than "user" confusion, Niall. I see total confusion. On 6/22/06, Niall Pemberton <[EMAIL PROTECTED]> wrote: My 2 cents. I agree with Don that we have created "user" confusion by having two competing frameworks. However I think if we're going to continue to have both then they should both be "first class citizens" - rather than relegating Shale. Personally, user confusion is secondary IMO to whether the developers still think theres merit in sharing the space and opportunities to co-operate. Since I'm not currently contributing anything to either SAF2 or Shale I'll leave it up to others to make that assesment - although to date there seems to have been little benefit. If others think the confusion is the #1 issue then the only solution IMO is for Shale to move home. Maybe we should "poll" the current committers on what they would prefer? Niall P.S. I was at a Sun "java roadshow" this week - they were putting out the message that Shale is the next Struts On 6/20/06, Don Brown <[EMAIL PROTECTED]> wrote: > As Shale and Action zero in on their first GA release, I don't think it is too > late to ask the question, "Does Struts really need two frameworks?" We have > been putting out the message, "two frameworks, one community", for almost a year > now, but I still sense a lot of confusion and even rejection from the Struts > community. The problem is for our whole history, Struts was a single framework, > what you went to if you wanted to structure your web application according to > Model2 principles. Our attempts to turn Struts into an umbrella project, I > feel, have failed. > > Struts Action 2 is seen, by some, as a simple rebranding of WebWork 2, and to be > honest, it really is at this stage. Struts Shale is seen as non-sequitur, > milking the Struts brand name. While these opinions are most extremely > expressed by our more radical members, they are also held to some degree by some > very smart, sensible people [1]. > > From a Struts committer perspective, Wendy made a good point to me the other > day saying that Struts lacks the single purpose or vision of most Open Source > projects. Despite our recent attempts to find common ground, Shale and Action > are still positioned as competing frameworks with no overlap. This division > leads to conflicts that suck the joy out of Open Source development. > > Recently, Struts Action 2 unified the programming models of action-based and > component-based development by allowing the developer to adopt an action-based > approach for an application, yet use JSF components and abilities where needed. > We have always said the desired end state would be to return Struts into a > unified framework, and I think we should jump on this chance now. > > I propose Struts return to its roots as a unified framework through building on > three libraries to make JSF and pure Servlet/JSP development easier. Namely, > I propose the Struts project to be the following subprojects, each with their > own release cycle: > > - Framework: Struts 2 > - Libraries: Struts Action, Shale and Struts Tags > > Struts would be the single framework the world would see. It would contain > support for Action-based, JSF-based, and hybrid applications. Its documentation > would promote the Struts Action controller as the preferred entry point, even if > only to be used for AJAX services. Its JSF library, Struts Shale, however, > could be used with a regular FacesServlet. JSF components and Struts Tags would > be equals when describing how to tackle the View of an application. > > Struts Action would be the core library driving Struts 2, replace Struts 1.x. > This library would be everything now known as Struts Action 2, but without the > UI components. We would aim for a solid Action-based library independent of the > view, much like Action 1.x. When we talked about what an Action JSR would look > like, this would be it. > > Struts Shale would be repositioned as a library, which I think is a better fit. > A framework to me is a comprehensive, one-stop-shop solution to create an > application. A library is a collection of independent features that can be used > in piecemeal. Therefore, I think a library is a better definition for Shale's > collection of JSF extensions. While Struts Action would definitely support > Shale, it would continue to be able to be used with pure JSF applications. > > Struts Tags would be the WebWork UI components, a library of re-usable, > stateless tags that can be used in Velocity, Freemarker, or JSP. They would > include current and future AJAX tags. These tags would most likely remain tied > to Struts Action 2, but not necessarily. > > How would this benefit Struts Action? By splitting of the tags, we can focus on > the core project and get it out the door quicker. By publicizing our JSF and > Shale integration, we would open our framework up to a broader audience. > > How would this benefit Struts Shale? Shale would also
Re: Does Struts really need two frameworks? (long)
Who would "they" be? Did anyone notice that Craig resurrected the failing JSF for Sun? I really like Sun but this has to be the worst thing they have managed to back. On 6/22/06, Niall Pemberton <[EMAIL PROTECTED]> wrote: My 2 cents. I agree with Don that we have created "user" confusion by having two competing frameworks. However I think if we're going to continue to have both then they should both be "first class citizens" - rather than relegating Shale. Personally, user confusion is secondary IMO to whether the developers still think theres merit in sharing the space and opportunities to co-operate. Since I'm not currently contributing anything to either SAF2 or Shale I'll leave it up to others to make that assesment - although to date there seems to have been little benefit. If others think the confusion is the #1 issue then the only solution IMO is for Shale to move home. Maybe we should "poll" the current committers on what they would prefer? Niall P.S. I was at a Sun "java roadshow" this week - they were putting out the message that Shale is the next Struts On 6/20/06, Don Brown <[EMAIL PROTECTED]> wrote: > As Shale and Action zero in on their first GA release, I don't think it is too > late to ask the question, "Does Struts really need two frameworks?" We have > been putting out the message, "two frameworks, one community", for almost a year > now, but I still sense a lot of confusion and even rejection from the Struts > community. The problem is for our whole history, Struts was a single framework, > what you went to if you wanted to structure your web application according to > Model2 principles. Our attempts to turn Struts into an umbrella project, I > feel, have failed. > > Struts Action 2 is seen, by some, as a simple rebranding of WebWork 2, and to be > honest, it really is at this stage. Struts Shale is seen as non-sequitur, > milking the Struts brand name. While these opinions are most extremely > expressed by our more radical members, they are also held to some degree by some > very smart, sensible people [1]. > > From a Struts committer perspective, Wendy made a good point to me the other > day saying that Struts lacks the single purpose or vision of most Open Source > projects. Despite our recent attempts to find common ground, Shale and Action > are still positioned as competing frameworks with no overlap. This division > leads to conflicts that suck the joy out of Open Source development. > > Recently, Struts Action 2 unified the programming models of action-based and > component-based development by allowing the developer to adopt an action-based > approach for an application, yet use JSF components and abilities where needed. > We have always said the desired end state would be to return Struts into a > unified framework, and I think we should jump on this chance now. > > I propose Struts return to its roots as a unified framework through building on > three libraries to make JSF and pure Servlet/JSP development easier. Namely, > I propose the Struts project to be the following subprojects, each with their > own release cycle: > > - Framework: Struts 2 > - Libraries: Struts Action, Shale and Struts Tags > > Struts would be the single framework the world would see. It would contain > support for Action-based, JSF-based, and hybrid applications. Its documentation > would promote the Struts Action controller as the preferred entry point, even if > only to be used for AJAX services. Its JSF library, Struts Shale, however, > could be used with a regular FacesServlet. JSF components and Struts Tags would > be equals when describing how to tackle the View of an application. > > Struts Action would be the core library driving Struts 2, replace Struts 1.x. > This library would be everything now known as Struts Action 2, but without the > UI components. We would aim for a solid Action-based library independent of the > view, much like Action 1.x. When we talked about what an Action JSR would look > like, this would be it. > > Struts Shale would be repositioned as a library, which I think is a better fit. > A framework to me is a comprehensive, one-stop-shop solution to create an > application. A library is a collection of independent features that can be used > in piecemeal. Therefore, I think a library is a better definition for Shale's > collection of JSF extensions. While Struts Action would definitely support > Shale, it would continue to be able to be used with pure JSF applications. > > Struts Tags would be the WebWork UI components, a library of re-usable, > stateless tags that can be used in Velocity, Freemarker, or JSP. They would > include current and future AJAX tags. These tags would most likely remain tied > to Struts Action 2, but not necessarily. > > How would this benefit Struts Action? By splitting of the tags, we can focus on > the core project and get it out the door quicker. By publicizing our JSF and > Shale integration, we would open
Re: Status of 1.3.5, 1.x, and loose ends
I will be helping with *all* of Struts (1.2.x, 1.3.x, 2.0 and Shale) for quite some time. I ain't going anywhere! -- James Mitchell On Jun 22, 2006, at 10:22 PM, Paul Benedict wrote: What is the status of 1.3.5? It sounds like it's almost baked. By the way, I am volunteering to continue adding features to 1.x. Michael says he is also. I read today Niall is too. Who else on the team still wishes to add features for this codebase? Just looking to know who is on the "inner team". PS: Have you locked down Struts bugzilla? I saw someone last week entered a bug into it (I got a bugzilla mail), when they should have done so in JIRA. -- Paul - How low will we go? Check out Yahoo! Messenger’s low PC-to-Phone call rates. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Status of 1.3.5, 1.x, and loose ends
I didn't pay attention to the JIRA migration, but I thought all bugzilla tickets were imported to JIRA. If that's true, do old email links matter? I mean, bugzilla won't be the eternal bug system -- eventually it will be displaced. Martin Cooper <[EMAIL PROTECTED]> wrote: On 6/22/06, Paul Benedict wrote: > > Well... What are the ramifications of removing bugzilla? Not sure what you mean by this. There's a great deal of history in there, and thousands of references into it from mail threads, etc. I wouldn't want to see that go away. Can we just get rid of any bugzilla links we have on our site? Advertise > jira. I thought we'd already done that, no? -- Martin Cooper Martin Cooper wrote: On 6/22/06, Paul Benedict > wrote: > > > > What is the status of 1.3.5? It sounds like it's almost baked. > > > > By the way, I am volunteering to continue adding features to 1.x. > Michael > > says he is also. I read today Niall is too. Who else on the team still > > wishes to add features for this codebase? Just looking to know who is on > the > > "inner team". > > > I just switched employers, starting today, and my new employer is not > currently using Struts. If we do in the future, it's not likely to be 1.x. > That being the case, the likelihood of me putting my own time into 1.x is > somewhat low now. > > PS: Have you locked down Struts bugzilla? I saw someone last week entered > a > > bug into it (I got a bugzilla mail), when they should have done so in > JIRA. > > > Bugzilla can only be locked down for new bug entry, which has been done. > Unfortunately, there isn't a way to stop people updating existing issues, > which is somewhat annoying. ;-( > > -- > Martin Cooper > > > -- Paul > > > > > > - > > How low will we go? Check out Yahoo! Messenger's low PC-to-Phone call > > rates. > > > > > > > - > Yahoo! Messenger with Voice. PC-to-Phone calls for ridiculously low rates. > - Want to be your own boss? Learn how on Yahoo! Small Business.
Re: Status of 1.3.5, 1.x, and loose ends
On 6/22/06, Paul Benedict <[EMAIL PROTECTED]> wrote: Well... What are the ramifications of removing bugzilla? Not sure what you mean by this. There's a great deal of history in there, and thousands of references into it from mail threads, etc. I wouldn't want to see that go away. Can we just get rid of any bugzilla links we have on our site? Advertise jira. I thought we'd already done that, no? -- Martin Cooper Martin Cooper <[EMAIL PROTECTED]> wrote: On 6/22/06, Paul Benedict wrote: > > What is the status of 1.3.5? It sounds like it's almost baked. > > By the way, I am volunteering to continue adding features to 1.x. Michael > says he is also. I read today Niall is too. Who else on the team still > wishes to add features for this codebase? Just looking to know who is on the > "inner team". I just switched employers, starting today, and my new employer is not currently using Struts. If we do in the future, it's not likely to be 1.x. That being the case, the likelihood of me putting my own time into 1.x is somewhat low now. PS: Have you locked down Struts bugzilla? I saw someone last week entered a > bug into it (I got a bugzilla mail), when they should have done so in JIRA. Bugzilla can only be locked down for new bug entry, which has been done. Unfortunately, there isn't a way to stop people updating existing issues, which is somewhat annoying. ;-( -- Martin Cooper -- Paul > > > - > How low will we go? Check out Yahoo! Messenger's low PC-to-Phone call > rates. > - Yahoo! Messenger with Voice. PC-to-Phone calls for ridiculously low rates.
Re: Status of 1.3.5, 1.x, and loose ends
Well... What are the ramifications of removing bugzilla? Can we just get rid of any bugzilla links we have on our site? Advertise jira. Martin Cooper <[EMAIL PROTECTED]> wrote: On 6/22/06, Paul Benedict wrote: > > What is the status of 1.3.5? It sounds like it's almost baked. > > By the way, I am volunteering to continue adding features to 1.x. Michael > says he is also. I read today Niall is too. Who else on the team still > wishes to add features for this codebase? Just looking to know who is on the > "inner team". I just switched employers, starting today, and my new employer is not currently using Struts. If we do in the future, it's not likely to be 1.x. That being the case, the likelihood of me putting my own time into 1.x is somewhat low now. PS: Have you locked down Struts bugzilla? I saw someone last week entered a > bug into it (I got a bugzilla mail), when they should have done so in JIRA. Bugzilla can only be locked down for new bug entry, which has been done. Unfortunately, there isn't a way to stop people updating existing issues, which is somewhat annoying. ;-( -- Martin Cooper -- Paul > > > - > How low will we go? Check out Yahoo! Messenger's low PC-to-Phone call > rates. > - Yahoo! Messenger with Voice. PC-to-Phone calls for ridiculously low rates.
Re: Status of 1.3.5, 1.x, and loose ends
On 6/22/06, Paul Benedict <[EMAIL PROTECTED]> wrote: What is the status of 1.3.5? It sounds like it's almost baked. By the way, I am volunteering to continue adding features to 1.x. Michael says he is also. I read today Niall is too. Who else on the team still wishes to add features for this codebase? Just looking to know who is on the "inner team". I just switched employers, starting today, and my new employer is not currently using Struts. If we do in the future, it's not likely to be 1.x. That being the case, the likelihood of me putting my own time into 1.x is somewhat low now. PS: Have you locked down Struts bugzilla? I saw someone last week entered a bug into it (I got a bugzilla mail), when they should have done so in JIRA. Bugzilla can only be locked down for new bug entry, which has been done. Unfortunately, there isn't a way to stop people updating existing issues, which is somewhat annoying. ;-( -- Martin Cooper -- Paul - How low will we go? Check out Yahoo! Messenger's low PC-to-Phone call rates.
Re: Status of 1.3.5, 1.x, and loose ends
On 6/22/06, Michael Jouravlev <[EMAIL PROTECTED]> wrote: I just created a first draft of what I envision as part of updated 1.3 documentation that describes new features for 1.3 ;-) http://wiki.apache.org/struts/StrutsComponents The WAR file is attached, see the bottom of the page. The WAR contains full source code of new and updated Struts classes. I would like to hear some opinions before I check this stuff in :-)) Umm, before the flame starts, I do not want to check in that exact code that is linked to a page. But I consider it is at least 80% ready ;-) I have not reimplemented couple of features that JSP Controls library has like triggering event via link or specifying explicit reload location via parameter. Michael. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Status of 1.3.5, 1.x, and loose ends
On 6/22/06, Paul Benedict <[EMAIL PROTECTED]> wrote: What is the status of 1.3.5? It sounds like it's almost baked. By the way, I am volunteering to continue adding features to 1.x. Michael says he is also. I read today Niall is too. Who else on the team still wishes to add features for this codebase? Just looking to know who is on the "inner team". I just created a first draft of what I envision as part of updated 1.3 documentation that describes new features for 1.3 ;-) http://wiki.apache.org/struts/StrutsComponents The WAR file is attached, see the bottom of the page. The WAR contains full source code of new and updated Struts classes. I would like to hear some opinions before I check this stuff in :-)) But not the old one "Action should not provide dispatching functionality, just because it should not" ;-) It does not hurt anyone. Also, this allows to build event notation right into action mapping definition. The sample looks and behaves exactly like this one: http://www.jspcontrols.net/jspcontrols-0.6-samples/login-struts/index.jsp I believe that the possibility to develop components with Struts Classic will be a killer feature. BTW, Paul, you were right, c:import works fine where jsp:include does not. So Struts components can be created quite easy. Michael. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Status of 1.3.5, 1.x, and loose ends
What is the status of 1.3.5? It sounds like it's almost baked. By the way, I am volunteering to continue adding features to 1.x. Michael says he is also. I read today Niall is too. Who else on the team still wishes to add features for this codebase? Just looking to know who is on the "inner team". PS: Have you locked down Struts bugzilla? I saw someone last week entered a bug into it (I got a bugzilla mail), when they should have done so in JIRA. -- Paul - How low will we go? Check out Yahoo! Messengers low PC-to-Phone call rates.
Re: Does Struts really need two frameworks? (long)
To me it makes more sense to have an Apache Faces TLP with lot's of subprojects. MyFaces as TLP is sometimes confusing too. Why all these component libs. For instance you can't mix Tobago with Tomahawk. ... but you can use Tobago with each JSF impl so, hey I am +1 for a Apache Faces TLP and +1 for having Shale its place there in. -Matthias On 6/22/06, Wendy Smoak <[EMAIL PROTECTED]> wrote: On 6/22/06, Matthias Wessendorf <[EMAIL PROTECTED]> wrote: > What about a "generic" Faces project, like portals or ws ? > Apache Faces. > > To me Shale fits fine into that. > > There - in an apache faces land - is enough space for: > Myfaces > Tomahawk > Tobago > Shale > Sandbox (well, our sandbox) > and soon Trinidad (aka ADF Faces donation) > > WDYT ? As far as I can tell, you've just proposed adding Shale and renaming the MyFaces project to just 'Faces'. :) Everything you listed (except Shale) is already at MyFaces, or coming soon. And I agree, Shale is a better fit with that list. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Matthias Wessendorf Aechterhoek 18 48282 Emsdetten blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Does Struts really need two frameworks? (long)
On 6/22/06, Matthias Wessendorf <[EMAIL PROTECTED]> wrote: What about a "generic" Faces project, like portals or ws ? Apache Faces. To me Shale fits fine into that. There - in an apache faces land - is enough space for: Myfaces Tomahawk Tobago Shale Sandbox (well, our sandbox) and soon Trinidad (aka ADF Faces donation) WDYT ? As far as I can tell, you've just proposed adding Shale and renaming the MyFaces project to just 'Faces'. :) Everything you listed (except Shale) is already at MyFaces, or coming soon. And I agree, Shale is a better fit with that list. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Does Struts really need two frameworks? (long)
Where is lives is less of a concern, but I'd be happy either as a TLP or as part of MyFaces. I'm very glad that Shale was accepted here and given time to grow and develop a community, but I think it's time to find a new home. I'd like to see Struts (the project) return to a focus on building a great Action framework, and let Shale continue to explore what can be done with JSF. yeah, there is some truth in it. But why Shale as a TLP? subproject of MyFaces is a -0 to me. What about a "generic" Faces project, like portals or ws ? Apache Faces. To me Shale fits fine into that. There - in an apache faces land - is enough space for: Myfaces Tomahawk Tobago Shale Sandbox (well, our sandbox) and soon Trinidad (aka ADF Faces donation) WDYT ? -Matthias -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Matthias Wessendorf Aechterhoek 18 48282 Emsdetten blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Does Struts really need two frameworks? (long)
On 6/22/06, Michael Jouravlev <[EMAIL PROTECTED]> wrote: In the meantime I want to make sure that SAF1 will not be simply removed from source repository just because SAF2 is the official future. The future belongs to the volunteers willing to do the work. So long as we have volunteers to work on the SAF1 codebase, then the work will continue. Trying to kill a codebase is a marketplace ploy. As an ASF project, our mandate is *not* "conquer the marketplace". Our mandate is to create an environment where a community of volunteers can collaborate on open source software. If the product finds marketplace acceptance, that's icing. But, it is *not* the point of the exercise. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Does Struts really need two frameworks? (long)
On 6/22/06, Hubert Rabago <[EMAIL PROTECTED]> wrote: On 6/22/06, Wendy Smoak <[EMAIL PROTECTED]> wrote: > This is going to be short, both because I'm on a deadline and because > I think the important points have already been covered. > > I'm not in favor of distributing Shale as a library behind a Struts 2 > that promotes the Action 2 controller. Shale's story from the > beginning has been that it is based on JSF. > > Where is lives is less of a concern, but I'd be happy either as a TLP > or as part of MyFaces. I'm very glad that Shale was accepted here > and given time to grow and develop a community, but I think it's time > to find a new home. I'd like to see Struts (the project) return to a > focus on building a great Action framework, and let Shale continue to > explore what can be done with JSF. > > -- > Wendy Thanks, Wendy, for finding the words I needed to express my own view! Now I won't have to write them up. I'm +1 to Wendy's views above. All of them. (Yes, I'm on a deadline, too). Hubert +1 Whatever happens to Shale, I hope that Struts project does not mutate to a simple "Struts == SAF2" equation; I want to be sure that SAF1 is kept alive as well. I know that to keep it alive someone (like me) has to make it happen by submitting new code. I am going to, I do work on it. In the meantime I want to make sure that SAF1 will not be simply removed from source repository just because SAF2 is the official future. I also hope that discussing improvements to SAF1 in dev list will not be considered mauvais ton. Michael. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Does Struts really need two frameworks? (long)
On 6/22/06, Greg Reddin <[EMAIL PROTECTED]> wrote: The problem with moving it is that we have to set up all the infrastructure to support it. Not just the bureaucracy of its own TLP and PMC, but the spreading thinner of the people involved. For example, how many Apache projects can somebody like Wendy support before she implodes :-) Actually, most of the Struts committers who work on Shale are already MyFaces committers, including Wendy. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Does Struts really need two frameworks? (long)
On 6/22/06, Niall Pemberton <[EMAIL PROTECTED]> wrote: P.S. I was at a Sun "java roadshow" this week - they were putting out the message that Shale is the next Struts I've seen this several times. People should clarify what they mean by this. Is it more like "The Queen is dead. Long live the Queen." or "Kobe is the next Michael / Wade is the next Kobe". HA! Who am I kidding? Of course they mean the former. If Shale becomes TLP or a MyFaces project, then it'll be the latter. Which, IIRC, is what Craig intends. Hubert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Does Struts really need two frameworks? (long)
My 2 cents. I agree with Don that we have created "user" confusion by having two competing frameworks. However I think if we're going to continue to have both then they should both be "first class citizens" - rather than relegating Shale. Personally, user confusion is secondary IMO to whether the developers still think theres merit in sharing the space and opportunities to co-operate. Since I'm not currently contributing anything to either SAF2 or Shale I'll leave it up to others to make that assesment - although to date there seems to have been little benefit. If others think the confusion is the #1 issue then the only solution IMO is for Shale to move home. Maybe we should "poll" the current committers on what they would prefer? Niall P.S. I was at a Sun "java roadshow" this week - they were putting out the message that Shale is the next Struts On 6/20/06, Don Brown <[EMAIL PROTECTED]> wrote: As Shale and Action zero in on their first GA release, I don't think it is too late to ask the question, "Does Struts really need two frameworks?" We have been putting out the message, "two frameworks, one community", for almost a year now, but I still sense a lot of confusion and even rejection from the Struts community. The problem is for our whole history, Struts was a single framework, what you went to if you wanted to structure your web application according to Model2 principles. Our attempts to turn Struts into an umbrella project, I feel, have failed. Struts Action 2 is seen, by some, as a simple rebranding of WebWork 2, and to be honest, it really is at this stage. Struts Shale is seen as non-sequitur, milking the Struts brand name. While these opinions are most extremely expressed by our more radical members, they are also held to some degree by some very smart, sensible people [1]. From a Struts committer perspective, Wendy made a good point to me the other day saying that Struts lacks the single purpose or vision of most Open Source projects. Despite our recent attempts to find common ground, Shale and Action are still positioned as competing frameworks with no overlap. This division leads to conflicts that suck the joy out of Open Source development. Recently, Struts Action 2 unified the programming models of action-based and component-based development by allowing the developer to adopt an action-based approach for an application, yet use JSF components and abilities where needed. We have always said the desired end state would be to return Struts into a unified framework, and I think we should jump on this chance now. I propose Struts return to its roots as a unified framework through building on three libraries to make JSF and pure Servlet/JSP development easier. Namely, I propose the Struts project to be the following subprojects, each with their own release cycle: - Framework: Struts 2 - Libraries: Struts Action, Shale and Struts Tags Struts would be the single framework the world would see. It would contain support for Action-based, JSF-based, and hybrid applications. Its documentation would promote the Struts Action controller as the preferred entry point, even if only to be used for AJAX services. Its JSF library, Struts Shale, however, could be used with a regular FacesServlet. JSF components and Struts Tags would be equals when describing how to tackle the View of an application. Struts Action would be the core library driving Struts 2, replace Struts 1.x. This library would be everything now known as Struts Action 2, but without the UI components. We would aim for a solid Action-based library independent of the view, much like Action 1.x. When we talked about what an Action JSR would look like, this would be it. Struts Shale would be repositioned as a library, which I think is a better fit. A framework to me is a comprehensive, one-stop-shop solution to create an application. A library is a collection of independent features that can be used in piecemeal. Therefore, I think a library is a better definition for Shale's collection of JSF extensions. While Struts Action would definitely support Shale, it would continue to be able to be used with pure JSF applications. Struts Tags would be the WebWork UI components, a library of re-usable, stateless tags that can be used in Velocity, Freemarker, or JSP. They would include current and future AJAX tags. These tags would most likely remain tied to Struts Action 2, but not necessarily. How would this benefit Struts Action? By splitting of the tags, we can focus on the core project and get it out the door quicker. By publicizing our JSF and Shale integration, we would open our framework up to a broader audience. How would this benefit Struts Shale? Shale would also be opened up to a broader, Action-based audience and wouldn't be seen as a competitor to Struts Action. It wouldn't lose its autonomy or pure JSF support. It would gain developer support as more Action-based apps would start to use JSF and need
Re: Does Struts really need two frameworks? (long)
On 6/22/06, Wendy Smoak <[EMAIL PROTECTED]> wrote: This is going to be short, both because I'm on a deadline and because I think the important points have already been covered. I'm not in favor of distributing Shale as a library behind a Struts 2 that promotes the Action 2 controller. Shale's story from the beginning has been that it is based on JSF. Where is lives is less of a concern, but I'd be happy either as a TLP or as part of MyFaces. I'm very glad that Shale was accepted here and given time to grow and develop a community, but I think it's time to find a new home. I'd like to see Struts (the project) return to a focus on building a great Action framework, and let Shale continue to explore what can be done with JSF. -- Wendy Thanks, Wendy, for finding the words I needed to express my own view! Now I won't have to write them up. I'm +1 to Wendy's views above. All of them. (Yes, I'm on a deadline, too). Hubert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Does Struts really need two frameworks? (long)
On 6/21/06, Don Brown <[EMAIL PROTECTED]> wrote: Again, Struts Action and Struts Shale would both retain their separate projects, codebases, and release cycles. Struts 2.0 is about building something on top of our Struts efforts to create a unified front to users. Users don't care about all the little projects, subprojects, and libraries we have; I think they just want something to help them build webapps - they want Struts 2.0. And as a committer, PMC member and Struts user, I want it too. This is going to be short, both because I'm on a deadline and because I think the important points have already been covered. I'm not in favor of distributing Shale as a library behind a Struts 2 that promotes the Action 2 controller. Shale's story from the beginning has been that it is based on JSF. Where is lives is less of a concern, but I'd be happy either as a TLP or as part of MyFaces. I'm very glad that Shale was accepted here and given time to grow and develop a community, but I think it's time to find a new home. I'd like to see Struts (the project) return to a focus on building a great Action framework, and let Shale continue to explore what can be done with JSF. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Does Struts really need two frameworks? (long)
On Jun 21, 2006, at 8:31 PM, Ted Husted wrote: We like to chatter about what's best for Struts, or what Struts is, but I think the key question is what's Shale, and what's best for Shale? I remain concerned that, after two years on a greenfield, there has not been a GA release of Shale. I have to wonder if keeping Shale here is stunting the community's growth. We've heard from Craig, but in order to make any kind of decision, I'd have to know how the other people working on Shale feel. Unfortunately, I don't have time to think through my response well enough right now, so if this seems disjointed, please forgive me. I'm not working directly on Shale (yet) but I am holding up a GA release :-) As I understand it one of the big reasons Shale is not to GA yet is because it can't go to GA until Tiles does. While it's waiting for Tiles, new innovations are happening that may be further holding up the release, but I've read on this list that Shale can't go GA until Tiles goes GA. I'm not sure if that's a dependency that can or should be removed. I see the advantages Shale brings to the table when working with JSF and I want it to succeed. The problem with keeping it here is that it may be perceived as a tagalong library to Struts no matter how we try to present it. The problem with moving it is that we have to set up all the infrastructure to support it. Not just the bureaucracy of its own TLP and PMC, but the spreading thinner of the people involved. For example, how many Apache projects can somebody like Wendy support before she implodes :-) Is it easier for her to add value to Shale's capabilities here than if Shale moved to a TLP? To clarify, if we build in improvements to Struts project management then we have to copy those improvements to Shale if it lives on its own whereas now we can just inherit them. The advantage of an umbrella project is that you don't have to copy things :-) And committers can migrate around to whatever their current needs are without having to switch PMC's or figure out which mailing list to post to. I'm conflicted as to the best approach. Living on its own will give Shale room to grow. Living here makes it easier for those of us who are already here to participate. I'll be involved in both as much as possible either way. Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Does Struts really need two frameworks? (long)
>From: "Dakota Jack" <[EMAIL PROTECTED]> > > These are not "camps" of a framework but competing frameworks. That is the > bottom line. Struts is dying and you guys, Gary, are killing it. Why not > man up and get your own space and try to survive on your own? > I'm not opposed to Shale moving out if the majority is in favor of webwork and apache "Struts" is really just about "a" framework. I'm an invited guest and my motivations are much simpler than what you are implying. Gary > On 6/21/06, Gary VanMatre wrote: > > > > >From: "Ted Husted" > > > > > > On 6/21/06, Don Brown wrote: > > > > Again, Struts Action and Struts Shale would both retain their separate > > > projects, > > > > codebases, and release cycles. Struts 2.0 is about building something > > on top > > > of > > > > our Struts efforts to create a unified front to users. Users don't > > care about > > > > all the little projects, subprojects, and libraries we have; I think > > they just > > > > want something to help them build webapps - they want Struts 2.0. And > > as a > > > > committer, PMC member and Struts user, I want it too. > > > > > > Wearing my PMC hat, I'd be surprised if that approach would well serve > > > the Shale community. You can dress it up anyway you want, but in the > > > end, this approach will have the effect of demoting Shale to an > > > appendage of SAF, rather than a framework in its own right. > > > > > > We like to chatter about what's best for Struts, or what Struts is, > > > but I think the key question is what's Shale, and what's best for > > > Shale? I remain concerned that, after two years on a greenfield, there > > > has not been a GA release of Shale. I have to wonder if keeping Shale > > > here is stunting the community's growth. > > > > > > We've heard from Craig, but in order to make any kind of decision, I'd > > > have to know how the other people working on Shale feel. > > > > > > > I think we could use some more Shale recruiters but I don't necessarily > > think > > that is because of lacking community support. I can think of several > > people > > that I feel have been worthy contributors but we have been very > > conservative. > > The SAF camp has recently been very active in recruiting anyone showing > > interest. > > > > I don't have a strong opinion either way. I remember someone saying that > > they have > > precious little time and I sympathize. Making this happen is really a team > > effort and > > you have to pick your battles. Even though I have not made the time to > > evaluate the > > latest in the action camp, I truly enjoy the exchange of ideas. > > > > If we continue to share a single community, I don't think that it is wise > > to force both > > camps into a single shoe box. On occasion we might want to get funky > > mixing styles > > but most like to play it safe, after all, it's about the right context. > > > > Gary > > > > > -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: Location for nightly builds
AFIAC, you're doing the work, and you can make the decision. :) -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Continnum Is Up
Over on the infrastructure list, there's a thread about MyFaces is running a nightly build for ADF in their Zone, and no one squawked, so I'd say go for it. -Ted. On 6/21/06, James Mitchell <[EMAIL PROTECTED]> wrote: Ok, I've added Action 1, Action 2, and Shale to Continuum. We need to decide on a schedule for regular builds. @Sean or anyone who knows, Can we do nightlies with Continuum? I didn't think that was possible, but I seem to remember some discussion about it somewhere. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Does Struts really need two frameworks? (long)
What is the problem? Who caused it? Bingo! Eureka? On 6/21/06, Don Brown <[EMAIL PROTECTED]> wrote: Paul Benedict wrote: > I don't see the point in bundling Shale into a "Struts 2.0" distribution. No > offense to anyone who develops Shale, but when we have packages called > "action2", it makes it pretty clear Shale is not Struts 2.0 -- only the action > framework. Separate frameworks, imo, get different names and distributions. I am > not offended Shale is within the Struts community, but I do not see it as the > torch bearer to the name Struts -- I do see that with the AF, which historically > holds the name. Again, Struts Action and Struts Shale would both retain their separate projects, codebases, and release cycles. Struts 2.0 is about building something on top of our Struts efforts to create a unified front to users. Users don't care about all the little projects, subprojects, and libraries we have; I think they just want something to help them build webapps - they want Struts 2.0. And as a committer, PMC member and Struts user, I want it too. Don - 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: Does Struts really need two frameworks? (long)
It would be impossible to pull off. Since Struts and JSF are inherently incompatible, there would be a my way or I will run away from home from Craig and an unwillingness of the Struts community to quit a true controller based framework. There is no way to make this marriage work. On 6/21/06, Patrick Lightbody <[EMAIL PROTECTED]> wrote: My quick thoughts: I think realistically either of the following two outcomes are positive developments for everyone: 1) We move in the direction of "Struts 2.0", which houses all SAF2 and Shale and get back for it being OK for folks to say, "I use Struts". We've all said we want to work together closer, but it's just talk until we take action to do so. This strategy, as proposed by Don in this thread, would be the first step in taking action. 2) Shale becomes a TLP. We continue to share code and ideas where it makes sense, but that is entirely optional. This is effectively what we have now, except that it would be formalized. I would prefer option #1, but I know it could be hard to pull off. Either way, both are good routes to go down and would be healthy for the community. Patrick - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=34915&messageID=68478#68478 - 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: Does Struts really need two frameworks? (long)
The success of Spring is not that "people like modularity". On 6/21/06, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: Ted Husted wrote: > So, in addition to including the Action 1.3 JARs in the SAF 2.0 > release, essentially, you are suggesting that we also include the > Shale 1.x JARs in the same distribution, so that anyone obtaining SAF2 > can use Action 1, Action 2, and/or Shale 1? Even though Don hasn't answered yet, I have to say I agree with Joe, and I hope that wasn't the idea... if we have learned anything from the success of Spring, it should be that people like modularity. Making sure that Action 1.3, SAF2 and Shale 1.x can be used together as desired is one thing, bundling them all together is another. I don't think that will make things easier or less confusing, on the contrary, I can't imagine it would do anything but make people scratch their heads even more. > -Ted. Frank - 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: Does Struts really need two frameworks? (long)
The problem is that there is no common ground. Pretence is great, but not really effective. It will bit you in the butt later. On 6/21/06, Don Brown <[EMAIL PROTECTED]> wrote: You make a lot of good points, and a strong argument for rallying around the JSF flag. To this end, Shale is a great idea and provides a nice realization of this approach. Undoubtedly, there are many developers who think similarly and may not ever be interested in the Action 2 controller, and Shale should always be there to make their lives easier. Others, however, may find uses for an Action 2 controller in a pure JSF application: * AJAX services that return JSON/XML - The Action 2 controller separates the rendering of the result from the method, so the method can return objects, and the configurable Result can handle the JSON or XML serialization. * Public high-load browsing pages - The Action 2 controller provides minimal overhead and the possibly of completely stateless, sessionless operation. Web designers can use Velocity, JSP, Freemarker, etc to create the pages. * Generated images - An application may have need to create charts, graphs, or other generated images. Action 2 provides a framework to separate the logic from the rendering, and even has built-in support for JFreeChart. * PDF reports - Likewise, there may be a need for generated PDF reports. Action 2 also has support for Jasper Reports, although any reporting engine can be easily plugged in. * Alternate view technologies - A section of the team may already be familiar with Velocity, Freemarker, or even XSLT and want to use that for the view. Finally, the Action 2 dispatcher is actually a ServletFilter, so it is very easy to have both controllers work side-by-side, even in the same request. Not every JSF application will have a need for Action 2, but putting them together in the same Struts 2.0 release provides a single place for the developer to learn about their options and see what fits best where. > * Philosophically, a framework built around JSF should encourage the > developer > to use facilities that are already there, so he or she will not need to > learn > new concepts. I agree common standards are important, and that is why we are looking to see how we can leverage standards like EL and JSF where we can. However, there are cases where the standard may be lacking and it is necessary to use a replacement (Freemarker/Velocity, OGNL, Spring, etc). > For navigation, "you'd use Action 2 navigation rather than navigation > handler" means that you're giving up on the tools around for JSF > navigation, > and forcing a beginner that is reading a JSF book to ignore that chapter > and learn something different. We'll want to look at how the existing SAF2 > navigation handler can delegate for scenarios where the developer wants to > use JSF navigation for some namespaces. True, but so does Clay, Facelets, and Shale dialogs change a "pure" JSF app, but as long as it is optional, it shouldn't be a big deal. That said, I really like your idea for delegation and am very open to putting that into Action 2. > It's definitely possible to merge Action 2 and JSF in an application -- > you've already done that. That's a tremendous benefit for the migration > use > cases, or those that just want to sprinkle some components without > migrating. For a new application, though, I don't care for the result, > because it adds complexity (over pure JSF based solutions), and requires > deveopers to deal with additional concepts and configuration files, without > enough corresonding benefits to make it worth it (IMHO, of course). But you really can't have it both ways - either you replace existing functionality or you have duplication. I think this is a problem even for Shale - duplicating resource loading, navigation, view templating, etc. > Doesn't it really come down to which front controller you choose as the > primary foundation of your architecture? Yes, but in making that decision, all things equal, you should choose the more generic/flexible one in front. Still, I hold to the argument that the the decision is invalid as there is a middle ground in using both. > Personally, I want to get out of the front controller business :-), and > leave that problem to the MyFaces and RI teams to compete on quality and > features. I'd rather add value by leveraging concepts that a JSF-oriented > developer already has to know about, rather than adding abstraction layers > so I can be agnostic about the front controller that is under the covers. And this is why Shale needs to continue, and I'd argue, continue to exist as part of the larger Struts community, and a step further, under a larger "Struts 2.0" product. I think despite providing multiple alternatives and solutions, there is a common narrative we can weave to create a unified Struts project. Don > > Don > > > Craig > - To un
Re: Does Struts really need two frameworks? (long)
The "Front Controller" is not really a controller. It is a child's tool for people who are challenged by OOP and need tool help. On 6/21/06, Craig McClanahan <[EMAIL PROTECTED]> wrote: Comments interspersed. On 6/21/06, Don Brown <[EMAIL PROTECTED]> wrote: > > Craig, thanks for your honesty and candor. I know this is a delicate > topic, and I appreciate you approaching the topic openly. LIkewise ... I may have sounded a bit grumpy in my response, but I don't ascribe any malicious intent to your proposal. A couple of clarifications: > > 1. I'm not proposing Shale _ever_ depend on Action 2, only that they > should work well together. In fact, I mean to start including Shale in > Action 2's web examples. In principle, that should work already for some things like ViewController, (but, if I read the current navigation handler right, you're not delegating so the "dialog" facility of Shale will not operate correctly at the moment). Proof is in the pudding of course, by actually writing such a sample app. 2. In a "pure JSF" environment, don't you think there is value in > using an Action 2 controller to handle things like JSON/XML remote > services? I'm finding more and more my Struts Actions return JSON > rather than HTML. This is how I see us working together even if you > don't use Action 2's JSF support. Two separate thoughts on this: * Technically, having an Action2 type handler for these things is certainly feasible, but not required. Shale Remoting does the same sorts of things for resource access, and supports dynamically mapping dynamic requests to an arbitrary method on a managed bean (i.e. it gets instantiated on demand and dependency injected), using standard JSF facilities, already. And it takes zero configuration if you like the default mapping algorithm. (Adding xwork interceptor chains around the call to the dynamic handler methods will be an easy add-on to this, for those who like that approach to providing services to the handler.) * Philosophically, a framework built around JSF should encourage the developer to use facilities that are already there, so he or she will not need to learn new concepts. That's why Shale does things like using method binding expressions to configure actions in the dialog subsystem ... binding an asynchronous callback is done exactly the same as binding a submit button to an action method (execute() in action framework terminology). Nothing new to learn. Leverages the managed beans facility exactly the same way. Easily usable by a JSF component itself that wants to encapsulate AJAX behavior or by client side JavaScript provided by the application. 3. Overlap areas like navigation, validation, messages, etc., are only > waiting on attention to be resolved. When using the Action 2 > navigation, it is my intention that the default configuration removes > overlap as much as possible. You'd use Action 2 navigation rather than > the NavigationHandler. Validations could be defined in the page or > could automatically be created from existing Action 2 validations (XML > or annotations), similarly to how Seam creates validations from > annotations. Messages integration is easily resolved by creating a > backing bean that provides messages using Action 2 apis. I fully > believe it is possible to merge Action 2 and JSF into a web application > in a seamless manner. There is a lot of space for implementing common frameworks we can share for doing things like validation -- for example, at JavaOne we talked a bit about a "Commons Validator 2.0" that could derive validation rules from annotations. But, at the end of the day, you still need different mechanisms to embed the particular annotations into the UI toolkit you're using (the UI tags in SAF, or the component tags in JSF). For navigation, "you'd use Action 2 navigation rather than navigation handler" means that you're giving up on the tools around for JSF navigation, and forcing a beginner that is reading a JSF book to ignore that chapter and learn something different. We'll want to look at how the existing SAF2 navigation handler can delegate for scenarios where the developer wants to use JSF navigation for some namespaces. It's definitely possible to merge Action 2 and JSF in an application -- you've already done that. That's a tremendous benefit for the migration use cases, or those that just want to sprinkle some components without migrating. For a new application, though, I don't care for the result, because it adds complexity (over pure JSF based solutions), and requires deveopers to deal with additional concepts and configuration files, without enough corresonding benefits to make it worth it (IMHO, of course). I guess what I'm saying is you could view this "overlap" in a negative > or positive light. I think the Struts project should put forth a > "preferred" approach, used in our quickstarts and tutorials. However, > that doesn't mean th
Re: Does Struts really need two frameworks? (long)
Thanks, Ted. Well said! On 6/21/06, Ted Husted <[EMAIL PROTECTED]> wrote: On 6/21/06, Don Brown <[EMAIL PROTECTED]> wrote: > I put this proposal out to help bring us together, > not precipitate a "divorce" :) We're not "divorcing" Tiles. Neither did we "divorce" any of the components that now live in the commons. We believed each of these codebase could attract a larger community on their own. We didn't abandon these components, we still use them. And, no matter where it lives, now it looks like we can still use Shale and other JSF components with SAF2. We can give away the cake and eat it too. As a PMC member, I'm concerned that, after all this time, Shale has still not had a GA release. We are all busy professionals, and we need a large community to push a release out the door. Shale has attracted a hard-working community, but it still has not attracted a large community. The question should be what is best for the Shale community? Where will the people working on Shale going to be the most productive? Where will they get the most help from other developers and users? At one time, the answer was here at Struts. But, 18 months later, maybe the answer has changed. Maybe the best thing for Shale would be to become a TLP, or a MyFaces subproject. I don't know myself. It's up to them that are doing the work. If the people working on Shale still think that this is the still the best location, then they have my support. But, I do think it is healthy to ask the question. -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: Does Struts really need two frameworks? (long)
This is so odd. You begin by recognizing the problem and trying to hide it. Now you deny the problem and want to continue it in spades. Everyone who knows anything about frameworks sees that these two frameworks are inherently incompatible. They have been from the start. That is the problem. Had Craig not had a career dependent presently on the success of JSF and also the pull at Struts, this mess would never have happened. On 6/21/06, Don Brown <[EMAIL PROTECTED]> wrote: Tim O'Brien wrote: > There is obviously a good deal > of exchange, but the frameworks "compete" (not my words). While this may be true politically, from a code perspective, I completely disagree. Just about every feature of Shale, AFAIK can easily be used with Action 2: Spring integration, clay, message bundles, basically anything that doesn't use an alternative NavigationHandler or Lifecycle. I think Shale is a great project and plan to use it where I can in Action 2 JSF examples as it really makes JSF easier. I think JSF is a very legitimate view option for Action 2 and Shale fills in JSF's gaps quite nicely. Don - 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: Does Struts really need two frameworks? (long)
The obvious truth is so easy to state. Thanks, Tim. On 6/21/06, Tim O'Brien <[EMAIL PROTECTED]> wrote: ...we're dealing with the ramifications of dismantling Jakarta from years ago.I actually think that this situation would have never arose if Struts and Shale were two sibling subprojects in a larger Jakarta project. But, the Board spoke years ago, and umbrella projects were broken up because of oversight concens. This highly dormant non-member votes TLP for Shale. This isn't meant as a slight towards Craig, rather I think that separating Shale into separate entity will help clarify the message of both Shale and SAF2. Otherwise every Shale page on the site is like an if/else clause "Use SAF2 if you like actions, but use shale if you...". I take a look at the db.apache.orgTLP, and I don't wish that fate upon Shale. Shale should be a TLP, the Shale site should be self-hosting. Struts is a TLP, the Struts site should be self-hosting. There is obviously a good deal of exchange, but the frameworks "compete" (not my words). On 6/21/06, Ted Husted <[EMAIL PROTECTED]> wrote: > > On 6/21/06, Craig McClanahan <[EMAIL PROTECTED]> wrote: > > If that means a (hopefully amicable) divorce, then so be it. > > If that's what the people working on Shale want, I doubt that the PMC > would oppose a change of venue. > > If that is the case, then the next question would be whether Shale > would be a better fit as a top-level ASF project, a subproject of > MyFaces, or somewhere else entirely? > > -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: Does Struts really need two frameworks? (long)
You cannot marry a pig and a fox, Don. Let's get honest. The only thing that is ever going to satisfy Craig is to get the Struts name for JSF, period. Let him go ahead and try to make it on his own. That won't work and its failure will keep JSF from continuing its trampy attempt to integrate with every Tom, Dick and Harry in town. On 6/21/06, Don Brown <[EMAIL PROTECTED]> wrote: Craig, thanks for your honesty and candor. I know this is a delicate topic, and I appreciate you approaching the topic openly. A couple of clarifications: 1. I'm not proposing Shale _ever_ depend on Action 2, only that they should work well together. In fact, I mean to start including Shale in Action 2's web examples. 2. In a "pure JSF" environment, don't you think there is value in using an Action 2 controller to handle things like JSON/XML remote services? I'm finding more and more my Struts Actions return JSON rather than HTML. This is how I see us working together even if you don't use Action 2's JSF support. 3. Overlap areas like navigation, validation, messages, etc., are only waiting on attention to be resolved. When using the Action 2 navigation, it is my intention that the default configuration removes overlap as much as possible. You'd use Action 2 navigation rather than the NavigationHandler. Validations could be defined in the page or could automatically be created from existing Action 2 validations (XML or annotations), similarly to how Seam creates validations from annotations. Messages integration is easily resolved by creating a backing bean that provides messages using Action 2 apis. I fully believe it is possible to merge Action 2 and JSF into a web application in a seamless manner. I guess what I'm saying is you could view this "overlap" in a negative or positive light. I think the Struts project should put forth a "preferred" approach, used in our quickstarts and tutorials. However, that doesn't mean that we should force developers into our way of thinking. Having options isn't necessarily bad. At this point, I really don't see a valid either/or framework approach debate: - If your application needs to be built by tool-dependent programmers, pure JSF is definitely the way to go. - If you prefer the pure JSF approach for other reasons, use a pure JSF framework, but perhaps use Action 2 to organize and deliver JSON/XML services. - If your application has a lot of Struts developers or stateless pages that need pure speed, but in sections you want to use fancy JSF components, use Action 2 as the controller and sprinkle in JSF where needed. - If you like Action-based approaches and don't need/like JSF components, just use Action 2. I hope we can agree that each of the above situations and solutions is valid, and make that our common ground. You may prefer the first couple, others the latter two. As a Struts project, we need to be of one mind in at least some things, and it is my hope Action 2's recent JSF integration attempts can help get us there. I put this proposal out to help bring us together, not precipitate a "divorce" :) Don Craig McClanahan wrote: > The short answer is that no, as long as I have any say in it, Shale will > not > morph to be dependent on Action2. SAF2 is too heavyweight and too > complexfor my tastes (see below for more about that remark), besdes the > fact > that it implements a lot of stuff that is redundant to what is already part > of JSF (and therefore Shale) that -- from the perspective of a new > application deveoper -- just complicates the picture instead of simplifying > it. > > Don't get me wrong ... SAF2 is a very elegant evolution of the > action-oriented controller paradigm. It's the paradigm that I have a > problem with. > > The complete longer answer will need to wait until I finish my analysis of > what Don did (but thanks for addressing WW-1357 right away!) to improve the > support for JSF components in SAF2. But the bottom line is that, in > 2006, I > have philosophical differences with action oriented frameworks (in the > sense > of what we see available today) as the right long term answer to designing > new Java based web applications -- Struts or WebWork or whatever. It's > wonderful that you are looking out for the migration use case, where people > need to add a few JSF components to their existing Struts or WebWork based > apps. No matter what happens, I can be comforted by the fact that people > wanting to add a bit of JSF component wizardry to their existing apps will > have that option. > > But the end result of an SAF2 + JSF based application is pretty much the > same, from an architectural viewpoint, as the result of a Struts 1.x + > Struts-Faces integration library + JSF based application. You end up using > only part of JSF (the UI components part ... valuable, yes, but not the > whole story). Worse, though, you end up with this wierd mismash of a front > controller in front of a front controller (mashed
Re: Does Struts really need two frameworks? (long)
Finally! On 6/21/06, Ted Husted <[EMAIL PROTECTED]> wrote: On 6/21/06, Craig McClanahan <[EMAIL PROTECTED]> wrote: > If that means a (hopefully amicable) divorce, then so be it. If that's what the people working on Shale want, I doubt that the PMC would oppose a change of venue. If that is the case, then the next question would be whether Shale would be a better fit as a top-level ASF project, a subproject of MyFaces, or somewhere else entirely? -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: Does Struts really need two frameworks? (long)
Heh, I have an idea, since JSF is so independent, why don't you start an open source project for JSF? Then we could see if people really want it and we could begin to tell what in the h -- e -- l -- l is going on with Struts. On 6/21/06, Craig McClanahan <[EMAIL PROTECTED]> wrote: The short answer is that no, as long as I have any say in it, Shale will not morph to be dependent on Action2. SAF2 is too heavyweight and too complexfor my tastes (see below for more about that remark), besdes the fact that it implements a lot of stuff that is redundant to what is already part of JSF (and therefore Shale) that -- from the perspective of a new application deveoper -- just complicates the picture instead of simplifying it. I agree, except for the suggestion that Struts, rather than JSF, is heavy weight. JSF is a misguided attempt to turn HTTP into Swing. Don't get me wrong ... SAF2 is a very elegant evolution of the action-oriented controller paradigm. It's the paradigm that I have a problem with. The complete longer answer will need to wait until I finish my analysis of what Don did (but thanks for addressing WW-1357 right away!) to improve the support for JSF components in SAF2. But the bottom line is that, in 2006, I have philosophical differences with action oriented frameworks (in the sense of what we see available today) as the right long term answer to designing new Java based web applications -- Struts or WebWork or whatever. It's wonderful that you are looking out for the migration use case, where people need to add a few JSF components to their existing Struts or WebWork based apps. No matter what happens, I can be comforted by the fact that people wanting to add a bit of JSF component wizardry to their existing apps will have that option. But the end result of an SAF2 + JSF based application is pretty much the same, from an architectural viewpoint, as the result of a Struts 1.x + Struts-Faces integration library + JSF based application. You end up using only part of JSF (the UI components part ... valuable, yes, but not the whole story). Worse, though, you end up with this wierd mismash of a front controller in front of a front controller (mashed teogether in the interceptor chain in the SAF2 implementation, but the same conceptually). Leading to continual decisions during the maintenance phase of a development project ... do I add a new page via action-framework navigation, or JSF navigation? Do I use the action framework's validation scheme, or JSFs? Am I forced to depend on Spring or whatever for dynamically created beans with dependency injection, or can I rely on the fact that JSF already provides a basic facility for this? Red Flags time! Indeed, one could make the same argument Don makes about consolidation, but in favor of adopting JSF as the fundantal controller architecture, and providing a full-up JSF implementation (probably based on MyFaces) that also incorporated XWork interceptors on each lifecycle phase (see SHALE-106 and SHALE-136). At least you could test such a thing for compliance with the JSF spec, and not have to hope that the folks that are utilizing some of the more critical JSF extension points are doing so in a manner that is going to be compatible with "pure JSF" component libraries and frameworks. Can't people see how nuts this whole talk is? Craig is the author of the problem that is faced here. Why would you think he can be the solution. This is all terribly neurotic at best. To me, it does not make sense for a framework to say "I adopt JSF" A framework cannot adapt JSF because JSF is a framework. Lord! but then have *redundant* implementations of things like validation and navigation and depdency injection and expression evaluation and This is fine for a migration story, but for new development it needlessly complicates the architecture of the resulting aplications. JSF already supports navigation (pluggable, if you want something completely different). Why should I be forced into SAF2 Results? JSF already supports a validation framework (easily extensible to client side validation, see Shale's feature in this respect). Why should I limit myself to what SAF2 offers? JSF has managed beans for basic dependency injection (including the abiltity to inject beans into a particular scope, which Spring is only now supporting in 2.x). Why should I go back to a single execute method (plus prepare() if you implement Preparable) as the only application events an action ever hears about, versus the four supported by Shale's ViewController? Why should I be required (or encouraged) to use Spring even if I don't need all the fancy stuff like constructor injection that Spring provides (which, by the way "works fine lasts a long time" with pure JSF already)? To say nothing of the fact that not using managed beans means you are passing on the resource injection facilities already available in Java EE 5. To say even more nothing about the fu
Re: Does Struts really need two frameworks? (long)
( I send this off list - I hate struts flamewars ) Jack, you are saying right things to people who fail to understand them... Struts was already brain-dead in 2001, and they will fail to assimilate webwork properly. (I will be first in line to fork it or apply to comimter status at opensymphony, or use my time and commiter powers to improve nanowar) I think your skills are better used on improving freemarker ;) ( since velocity guys are not doing their work at all... ) regards, --- Dakota Jack <[EMAIL PROTECTED]> wrote: > I laughed when you were made a committer, Michael. > That convinced me that > the end was inevitable. However, this I don't find > at all funny. I really > would like to see Struts succeed. > > On 6/20/06, Michael Jouravlev <[EMAIL PROTECTED]> > wrote: > > > > On 6/20/06, Don Brown <[EMAIL PROTECTED]> wrote: > > > As Shale and Action zero in on their first GA > release, I don't think it > > is too > > > late to ask the question, "Does Struts really > need two frameworks?" > > > > I bet DJ and JR are laughing their asses off. > > > > > - > > 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~ > [ Konstantin Pribluda http://www.pribluda.de ] Still using XDoclet 1.x? XDoclet 2 is released and of production quality. check it out: http://xdoclet.codehaus.org __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Does Struts really need two frameworks? (long)
Struts is not advocating a preference? The Orwellian Speak continues. Struts is Action. Struts is NOT JSF. Struts does not have a preference because Struts IS one of the alternatives and one of the alternatives is NOT Struts. I get a kick out of Don calling people willing to state that the king has no clothes are radical. The people who are not radical are the people willing to tell the half truths to keep Craig, and other JSF career dependent people, happy. On 6/21/06, Ian Roughley <[EMAIL PROTECTED]> wrote: If the goal is to separate the life cycles or to share code, then I am all for it. But I don't think the end users perception is going to be any different by this proposed change. The question is still going to be "are we going to use a JSF or action framework?" Struts is not advocating a preference (and I don't think it should) and I believe this is the confusion for most people when making a choice. /Ian Don Brown wrote: > Ted Husted wrote: >> As for making the UI tags an independant extension, a al Tiles, that >> sounds good too. (Even better if we include the "value added" Ajax >> support.) But I don't know if we want to hold back the SAF 2.0.0 to >> make it happen. But, for phase 2, sure! > Actually, I'm thinking splitting off the tags would help us get SAF > 2.0.0 out the door sooner. A lot of our remaining tickets are for > AJAX tags, which would be in this new project. As for the Tiles > comparison, that is exactly what I was going for. > > And to be clear, the tags, at least for the near term, would stay > dependent on Struts Action 2. The reason to split them off would be > to give them their own release cycle and make Struts Action 2 releases > more focused and quicker. The tags have their own group of interested > committers, so I don't see a repeat of our last spinoff attempt. :) > > Don > >> >> -Ted. >> >> - >> 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] -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~
Re: Does Struts really need two frameworks? (long)
That's right. The problem is the presence of any and all JSF hacks. On 6/21/06, Alexandru Popescu <[EMAIL PROTECTED]> wrote: Hi everybody! I've read this thread a couple of times, because I was having a somehow weird sentiment while doing it. Now, I think I have figured it out :-). So, please bear with me for the short following paragraphs (I am not a good writer yet): 1. even if I don't know too many details about Struts history, I somehow agree with Don's opinion that changing it to be an umbrella project may become confusing for the existing users, for new users and for users that might consider migrating to newer approaches. But... 2. this single package, solve-all idea, is something that RoR prooved to be the wrong approach. I am playing now with RoR and I frankly don't see anything in RoR over WebWork (really). But, what I am seeing behind RoR is a very simple idea: drop it in and it will help you build very quickly an web app (or at least some of them). And the single-package-solves-all is exactly the opposite. People will not be able to just drop in a couple of jars (for people knowing RoR, read it a couple of gems) with their dependency managed directly and start working on your app in a couple of seconds. It will be something like: drop this in and now let's start and think: what other piece do I need? Is it actions? Is it JSF? Is it X or Y? What dependencies should I use for X over Y? And so, we are once again gonna fail the simplicity that RoR proposed to web development (and IMO this is the sole real contribution). Convention over configuration cannot work with a big-solve-all package/framework. And this will leave the Java web apps world for another period as a "zombie in the dark". WebWork has tried to adapt to this new approach proposed by RoR. And it was nice to see it. We may have a few more ideas to make it even simpler in the near future. But this will not work with the big-solve-all approach. Indeed, this may look at the first glance as another, but opposite radical view. It is only my opinion, as a guy being involved in the Java world for 10 years and seeing everywhere people thriving to take a decission. IMO another big-all-solve-all approach will not be able to solve this problem, nor to simplify it in the future. BR, ./alex -- .w( the_mindstorm )p. On 6/21/06, Don Brown <[EMAIL PROTECTED]> wrote: > Ted Husted wrote: > > As for making the UI tags an independant extension, a al Tiles, that > > sounds good too. (Even better if we include the "value added" Ajax > > support.) But I don't know if we want to hold back the SAF 2.0.0 to > > make it happen. But, for phase 2, sure! > Actually, I'm thinking splitting off the tags would help us get SAF > 2.0.0 out the door sooner. A lot of our remaining tickets are for AJAX > tags, which would be in this new project. As for the Tiles comparison, > that is exactly what I was going for. > > And to be clear, the tags, at least for the near term, would stay > dependent on Struts Action 2. The reason to split them off would be to > give them their own release cycle and make Struts Action 2 releases more > focused and quicker. The tags have their own group of interested > committers, so I don't see a repeat of our last spinoff attempt. :) > > Don > > > > > -Ted. > > > > - > > 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] -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~
Re: Does Struts really need two frameworks? (long)
Why in the world cannot you people see that JSF just does not fit? Is it impossible to accept the truth? Would Craig be too angry? On 6/20/06, Ted Husted <[EMAIL PROTECTED]> wrote: Yes, it would be helpful to find a good way to make JSF easier to use in a conventional Action-based application, much the same way we are trying to make Ajax easier to use in SAF2. Our first attempt (as a project) at JSF/Action integration was the Struts JSF taglib. The promise here was to migrate a Struts JSP to JSF, one page a time. It sounded good, but unfortunately, it didn't' work out as well in practice. Our second attempt is Shale. Since we couldn't find a way to integrate JSF into an Action-based framework, we erased the whiteboard and started over. While this approach seems to be working well for people ready for a clean break, it is not creating a migration path for Action-centric developers. Our third attempt at integration is the recent work that tacks JSF components onto SAF2. If this third attempt pans out in practice, and works with extensions like Clay, then, sure, we might be able to position Shale as the JSF extension to SAF2. Much like we're talking about creating an Ajax extension based on DWR or Dojo. As for making the UI tags an independant extension, a al Tiles, that sounds good too. (Even better if we include the "value added" Ajax support.) But I don't know if we want to hold back the SAF 2.0.0 to make it happen. But, for phase 2, sure! -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: Does Struts really need two frameworks? (long)
I laughed when you were made a committer, Michael. That convinced me that the end was inevitable. However, this I don't find at all funny. I really would like to see Struts succeed. On 6/20/06, Michael Jouravlev <[EMAIL PROTECTED]> wrote: On 6/20/06, Don Brown <[EMAIL PROTECTED]> wrote: > As Shale and Action zero in on their first GA release, I don't think it is too > late to ask the question, "Does Struts really need two frameworks?" I bet DJ and JR are laughing their asses off. - 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: Does Struts really need two frameworks? (long)
These are not "camps" of a framework but competing frameworks. That is the bottom line. Struts is dying and you guys, Gary, are killing it. Why not man up and get your own space and try to survive on your own? On 6/21/06, Gary VanMatre <[EMAIL PROTECTED]> wrote: >From: "Ted Husted" <[EMAIL PROTECTED]> > > On 6/21/06, Don Brown wrote: > > Again, Struts Action and Struts Shale would both retain their separate > projects, > > codebases, and release cycles. Struts 2.0 is about building something on top > of > > our Struts efforts to create a unified front to users. Users don't care about > > all the little projects, subprojects, and libraries we have; I think they just > > want something to help them build webapps - they want Struts 2.0. And as a > > committer, PMC member and Struts user, I want it too. > > Wearing my PMC hat, I'd be surprised if that approach would well serve > the Shale community. You can dress it up anyway you want, but in the > end, this approach will have the effect of demoting Shale to an > appendage of SAF, rather than a framework in its own right. > > We like to chatter about what's best for Struts, or what Struts is, > but I think the key question is what's Shale, and what's best for > Shale? I remain concerned that, after two years on a greenfield, there > has not been a GA release of Shale. I have to wonder if keeping Shale > here is stunting the community's growth. > > We've heard from Craig, but in order to make any kind of decision, I'd > have to know how the other people working on Shale feel. > I think we could use some more Shale recruiters but I don't necessarily think that is because of lacking community support. I can think of several people that I feel have been worthy contributors but we have been very conservative. The SAF camp has recently been very active in recruiting anyone showing interest. I don't have a strong opinion either way. I remember someone saying that they have precious little time and I sympathize. Making this happen is really a team effort and you have to pick your battles. Even though I have not made the time to evaluate the latest in the action camp, I truly enjoy the exchange of ideas. If we continue to share a single community, I don't think that it is wise to force both camps into a single shoe box. On occasion we might want to get funky mixing styles but most like to play it safe, after all, it's about the right context. Gary > -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: Does Struts really need two frameworks? (long)
This is the same thing except giving the real problem, JSF force fit into Struts, more importance. This intensifies rather than solves the problem. Action and JSF are two different web frameworks. That is the bottom line. Adroit talk, fancy speeches, etc., cannot change that and only serve to diminish the little confidence people have in those who try to talk the problem away instead of solving it. Let JSF make its own way. On 6/20/06, Don Brown <[EMAIL PROTECTED]> wrote: As Shale and Action zero in on their first GA release, I don't think it is too late to ask the question, "Does Struts really need two frameworks?" We have been putting out the message, "two frameworks, one community", for almost a year now, but I still sense a lot of confusion and even rejection from the Struts community. The problem is for our whole history, Struts was a single framework, what you went to if you wanted to structure your web application according to Model2 principles. Our attempts to turn Struts into an umbrella project, I feel, have failed. Struts Action 2 is seen, by some, as a simple rebranding of WebWork 2, and to be honest, it really is at this stage. Struts Shale is seen as non-sequitur, milking the Struts brand name. While these opinions are most extremely expressed by our more radical members, they are also held to some degree by some very smart, sensible people [1]. From a Struts committer perspective, Wendy made a good point to me the other day saying that Struts lacks the single purpose or vision of most Open Source projects. Despite our recent attempts to find common ground, Shale and Action are still positioned as competing frameworks with no overlap. This division leads to conflicts that suck the joy out of Open Source development. Recently, Struts Action 2 unified the programming models of action-based and component-based development by allowing the developer to adopt an action-based approach for an application, yet use JSF components and abilities where needed. We have always said the desired end state would be to return Struts into a unified framework, and I think we should jump on this chance now. I propose Struts return to its roots as a unified framework through building on three libraries to make JSF and pure Servlet/JSP development easier. Namely, I propose the Struts project to be the following subprojects, each with their own release cycle: - Framework: Struts 2 - Libraries: Struts Action, Shale and Struts Tags Struts would be the single framework the world would see. It would contain support for Action-based, JSF-based, and hybrid applications. Its documentation would promote the Struts Action controller as the preferred entry point, even if only to be used for AJAX services. Its JSF library, Struts Shale, however, could be used with a regular FacesServlet. JSF components and Struts Tags would be equals when describing how to tackle the View of an application. Struts Action would be the core library driving Struts 2, replace Struts 1.x. This library would be everything now known as Struts Action 2, but without the UI components. We would aim for a solid Action-based library independent of the view, much like Action 1.x. When we talked about what an Action JSR would look like, this would be it. Struts Shale would be repositioned as a library, which I think is a better fit. A framework to me is a comprehensive, one-stop-shop solution to create an application. A library is a collection of independent features that can be used in piecemeal. Therefore, I think a library is a better definition for Shale's collection of JSF extensions. While Struts Action would definitely support Shale, it would continue to be able to be used with pure JSF applications. Struts Tags would be the WebWork UI components, a library of re-usable, stateless tags that can be used in Velocity, Freemarker, or JSP. They would include current and future AJAX tags. These tags would most likely remain tied to Struts Action 2, but not necessarily. How would this benefit Struts Action? By splitting of the tags, we can focus on the core project and get it out the door quicker. By publicizing our JSF and Shale integration, we would open our framework up to a broader audience. How would this benefit Struts Shale? Shale would also be opened up to a broader, Action-based audience and wouldn't be seen as a competitor to Struts Action. It wouldn't lose its autonomy or pure JSF support. It would gain developer support as more Action-based apps would start to use JSF and need Shale. How would this benefit Struts Tags? The tags could evolve quicker with faster releases due to less code. They would be free to add new marginal features without worrying about bloating Struts. This project would be analogous to MyFaces Tomahawk as a library of components. How would this benefit the Struts community? Finally, Struts returns to its roots as a single framework. While pieces of it may be usable outsi
