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 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 outside the > Action-based controller like Shale, it becomes the single place you go to solve > your application development needs. The documentation would be unified and the > supporting committer community in step. If you wanted the whole framework, you > download Struts. If you just want one of the libraries, they are available ala > carte as well. > > This proposed change is primarily one of message and vision, and should have > minimal impact on current development activity. With the next generation of > books and conferences in the works, I think it is important to develop a clear > message to the Struts community and minimize any confusion. > > The bottom line is we want Struts to be the place to go to make web development > easier, faster, with less hassles. I think this proposal provides the vision to > make that happen. > > Don > > [1] http://www.oreillynet.com/onjava/blog/2006/06/isnt_rails_supposed_to_change.html > > > --------------------------------------------------------------------- > 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~
