Collaboration: At the Extremities of Extreme
Jason Ayers share the observations he made watching a team of developers collaborating in real time on the same code base, pushing XP, pair programming and continuous integration to their extremes.
News
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Struts and Shale (JSF) Finally Part Ways
Posted by Floyd Marinescu on Jul 04, 2006
Shale began as a proposal for Struts 2.0's migration to JSF, but the Struts community itself never got fully committed to JSF itself which takes a component-based instead of action based approach to web development. Shale thus became a subproject to Struts to provide a JSF alternative, where it has been in develompent for almost 2 years and is now approaching its first stable release.
The discussion on the Struts list began with Don Brown proposing unification: "Struts would be the single framework the world would see. It would contain support for Action-based, JSF-based, and hybrid applications. " Struts & Shale founder Craig McClanahan (who is also the main proponent for Shale) later responded quite bluntly: "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. " Craig went on: "for new developers, I would much prefer to compete with SAF2 than to cooperate with it. If that means a (hopefully amicable) divorce, then so be it."
In response to this, Ted Husted wrote: "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? " The discussion then had most of the WebWork, Struts, and JSF personalities weigh in with some proposing integration and others suggesting that parting ways while cooperating where it makes sense being the best approach.
The outcome was Shale finally parting ways and becoming it's own project. Shale will no longer benefit from the incredible power of the Struts marketing brand, but the community itself has voted as the Struts community overwhelmingly is in favour of continuing as a modern action oriented framework via migration to WebWork 2.3.
This over all news is good both for Struts and JSF developers, as the industry will not have clarity and also both camps will have greater freedom to evolve separately.
Interestingly, the over all debate possibly revealed some of the fundamental conficts of interest between the java development community and the java vendor community, with Craig himself stating in one post that "Struts Action Framework 2 is a much better (technical) approach to the problems that Struts 1.x targeted," but earlier making the true motivations behind JSF obvious:
I want to focus on attracting a much larger audience of developers who are *not* O-O professionals, whose idea of "code reuse" is cut-n-paste, and who might actually prefer to use tools (SAF2's fundamental architecture is pretty much untoolable, even if someone were motivated to spend the effort to build tooling around it).
Related news: InfoQ.com/jsf
RelatedVendorContent
Improve Java Garbage Collection, Runtime Execution, and JVM visibility with Zing
Using Drools? See what you're missing! Get the Power of Drools with the Assurance of Red Hat
18 agile and lean practices for effective software development governance
Missing the Buck
by
Jacob Hookom
Posted
Re: Missing the Buck
by
Floyd Marinescu
Posted
Re: Missing the Buck
by
Jacob Hookom
Posted
Passing the Point
by
Corby Page
Posted
Re: Passing the Point
by
Alexandre Poitras
Posted
Re: Passing the Point
by
Adam Winer
Posted
Re: Passing the Point
by
Don Brown
Posted
Re: Passing the Point
by
Craig McClanahan
Posted
Re: Passing the Point
by
Craig McClanahan
Posted
-
Hi Jacob,
We are all for driving traffic to peoples blogs (yes InfoQ has actually gotten big enough in the month since it's launched that it can do that), but it would be more polite (and possibly more effective for you) to also comment in this thread to express your point as well as link off to your blog.
Thanks for participating. Respectfully,
Floyd -
...to also comment in this thread to express your point as well as link off to your blog.
I'll take note of that in the future :-) Respectfully, the blog does point back to and mentions InfoQ.com. -
I like Jacobs's suggestions on collaboration. He says that both SAF2 and JSF should:
- Use the same annotations to describe validation constraints
- Utilize the standardized JPA/EJB for RAD
- Use the same variable/context mechanism, such as the EL-API
- Action signatures are a no-arg method that return a String
- Standardized business component concepts
- Use lower-level interceptor concepts from EJB that aren't deployment specific
- Continue using common annotations
I think that WW2 has nailed the action framework stuff, and I'm very happy implementing my actions with it. However, it is taking a lot of awkward missteps into the AJAX component space, and I get jealous of JSF's ability to pick and choose third party components to drop into the UI.
I would consider "sprinkling" JSF into my WW2 stuff per Don's suggestion. But as Jacob notes, there are still enough unnecessary incompatibilities between the frameworks that it is too much of a pain in the ass to do so.
JSF seems to be going through an identity crisis that is reminiscent of JINI. First, JSF was presented as a tooling platform, then its proponents got very defensive and claimed that JSF worked best without tooling. Now we've come full circle, where even Craig admits that JSF is only superior in a tooling context.
In the end, it looks like JSF's primary selling point will be its vendor support, which will exist purely by virtue of being forced into the JEE spec. That's probably not going to be enough to win me over. - Use the same annotations to describe validation constraints
-
JSF seems to be going through an identity crisis that is reminiscent of JINI. First, JSF was presented as a tooling platform, then its proponents got very defensive and claimed that JSF worked best without tooling. Now we've come full circle, where even Craig admits that JSF is only superior in a tooling context.
The problem is people absolutly want to put a label on JSF. After having worked with it, I can say JSF is a nice platform to work with without using any tools. But some people aren't comfortable with OO and prefer to use RAD tools. Those 2 facts aren't exclusive. From what I understand, Craig didn't say JSF was only superior in a tooling context but that he is looking to attract people coming from VB or Delphi. It doesn't mean JSF is a dirty solution. Not at all. To work with JSF, tools support isn't essential but available if you want it. -
We designed JSF first as a solid, component-centric framework, and second as a framework for tools. Whatever the marketing folks did with that (or what Craig is quoted as saying) is not so much my concern. I'm still baffled that the fact that we actually thought about tooling in the first version is somehow a negative thing in anyone's mind - but no one ever suggested on the expert group that JSF was or should be a tooling platform. (I'm also amazed that anyone would claim that any framework - JSF, Hibernate, WebWorks, etc., is somehow best without tooling.)
I agree entirely with Jacob's suggestions for collaboration among the frameworks - and JSR 299 looks like a fine place to work through many of these issues. Splitting up and going our separate ways, and leaving it at that, seems like a poor route for all of our users. -
When I started the thread on Struts dev, my goal was to unify the two groups, not provoke a "divorce". My point was JSF is a solid component framework, and Struts 2 is a proven controller, and the two can and should work together seamlessly. In a perfect world, there would be an action-based controller JSR that could optionally be used with JSF components, and both JSR's would use the same EL, annotations, validations, localization, etc.
The Struts 2-style controller is much more powerful than the JSF servlet, and supports other types of views and workflows. On the other hand, JSF, in my opinion, has the better component framework and can handle complex, event-based components, encouraging a component marketplace. It was said that JSF was a view technology that had to define some controller capabilities to get by, so why not replace that controller with a Struts 2-style MVC controller, and let JSF get back to what it is best at? -
JSF seems to be going through an identity crisis that is reminiscent of JINI. First, JSF was presented as a tooling platform, then its proponents got very defensive and claimed that JSF worked best without tooling. Now we've come full circle, where even Craig admits that JSF is only superior in a tooling context.
Sigh ... that is an incorrect misconception of what I am actually saying, which can be summarized very succinctly:
- JSF apps can be hand authored just as
easily as apps in your favorite action
oriented MVC framework. - JSF was, *in addition*, designed to make
it easy to support with tools. - The proof is in the pudding ... besides the
existing IDE support for hand authoring JSF apps
that is equivalent to what you'll see for
frameworks like Struts, you also get to
choose from IDEs focused on visual development
if you like that approach.
Craig - JSF apps can be hand authored just as
-
In the end, it looks like JSF's primary selling point will be its vendor support, which will exist purely by virtue of being forced into the JEE spec. That's probably not going to be enough to win me over.
You might want to think about whether the kind of vendor support you see for JSF today is even technically feasbile for your favorite action oriented framework. Supporting graphical help in updating configuration files is pretty easy (and commonly available for frameworks like Struts 1 today). Supporting development with visual components, on the other hand, is not particularly easy when there is no visual component model, let alone libraries of components that correspond to that model.
NOTE - it may well be that you are not won over by this ... and that's fine. In particular, if you like action oriented frameworks, you can't go wrong with Struts 2 ... it is a very elegant evolution of this paradigm. But, I'm thinking that the number of people who can appreciate that elegance is a heck of a lot smaller than the potential number of developers whose lives could be made better by a framework that doesn't require them to understand that elegance in order to benefit from it.
Craig
9 comments
Watch Thread Reply