You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Don Brown <mr...@twdata.org> on 2005/10/10 21:54:22 UTC
Web Framework Consolidation
Consolidation is a relatively unknown concept in the crowded web
framework space. While most frameworks are open source allowing
cross-pollination, collaboration is still rare resulting in duplicated
efforts and confusion for the end user. Struts Ti, a next-gen project
in the Struts sandbox, tried to buck the trend by building on WebWork
rather than wasting its time writing yet another Model2 framework.
Taking this level of cooperation to the next level, developers from four
popular web frameworks - Struts, Spring, WebWork, and Beehive, have
gotten together to discuss the possibility of consolidating their
efforts into a new project, termed Clarity. Clarity would be an
action-based MVC framework that combines the commonality of the four
aforementioned frameworks into one that can be built upon by all.
These discussions have just began, and while no one has "officially"
signed on, I thought I should bring it before the Struts community for
feedback. There is still much to work out, but I want to keep the
community involved from the beginning.
I personally am excited about this project and think it will be
beneficial to users and developers alike. The Struts Classic code base
is showing its age, but speaking as a developer who maintains old Struts
apps, few people have the time and budget to rewrite them from scratch
with a more disparate framework like Shale or Wicket. I think Clarity
would be a much easier migration for existing Struts applications and
developers, yet support key standards like Portlets and JSF.
Attached is two messages in a private email thread between Patrick
Lightbody (WebWork), Keith Donald (Spring), Rich Feit (Beehive), and me,
that started the Clarity discussion. We plan to have a public email
list for Clarity discussion, but it hasn't been setup yet.
What I'm looking for from the Struts community is if you think this is a
good idea, and if you do, what we need to do to make it work.
Personally, I don't expect Struts or even Struts Classic going away at
all even if we agreed Clarity is migration path, so this isn't an
either/or discussion.
Again, this is _NOT_ a project announcement meant for the world, only
the beginning of a discussion about the idea of consolidating a few web
frameworks and how Struts fits in with this. Looking forward to the
comments,
Don
=== Initial kickoff by Patrick Lightbody from WebWork ===
Patrick Lightbody wrote:
> (Warning: long email ahead. Don't worry, this isn't usually my style
> and I'll stick to brief emails moving forward.)
>
> Hey guys -- this is the official "kickoff" of the project we've all
> been talking about. Keith had a great code name for the project:
Clarity.
>
> Before I get started, I just wanted to clarify the following people
> involved and what their roles are:
>
> - Keith represents the Spring team, including the Spring MVC and
> Spring WebFlow process. For now he will handle all the communication
> between this project and the rest of the Spring folks.
> - Jason is the primary technical representative from the WebWork team.
> While I can add some info, I expect Jason will offer most of the
> technical thoughts. Jason uses Spring and has a lot to offer here.
> - Don Brown is a Struts committer and represents the Struts team (or
> at least some of them). Don is the force behind Struts Ti and can
> provide a lot of insight as user of WebWork and XWork, with both a
> Struts and simplified "flavor" to it.
> - Rich represents the Beehive team and also works on the Struts Ti
> project. Rich will represent most of the Beehive input.
> - Finally, I hope to, more than anything, act as a facilitator for
> this whole project. Obviously I have a WebWork-slanted perspective, but
> I believe that facilitating this process is more important than any set
> of features or implementations choices.
>
> As I mentioned to you guys individually, I think the best way to move
> forward is to take the following steps. I've taken a stab at the first
> item as well.
>
> 1) Establish the rules: a small, agreed upon list of rules that we
> promise to adhere to while working on this project. These will be
> especially important in the early phases.
>
> 1) Complete a statement: we need to come up with a single paragraph
> that sums up this effort. It should include the desire to work
> together, the desire for clarity in the java web space, and the desire
> to move beyond "petty" differences about implementation choices. In
> short, this mission statement, when releases as a press release to the
> entire community, should be powerful enough to get everyone excited
> about it and know for sure that _this_ is the effort that will bring
> web development productivity back to the Java camp.
>
> 2) Announce the project: we need to gather excitement around this as
> soon as possible. Doing so will not only get us early feedback from the
> community, it will most likely stave off a few more web frameworks from
> being created (I found two more just today - eek!).
>
> 3) Set up a neutral place to host the project, including SVN, wiki, bug
> tracker, etc. This place must be detached from Jakarta/Struts, Spring,
> and OpenSymphony and must stay that way until we all feel comfortable
> working together. That will likely happen about half way through
step 4...
>
> 4) Now for the hard part: map out a technical implementation.
>
> 5) Release and re-establish Java as the place to build web
> applications. I hope for this to happen within 8-12 months time,
> starting today.
>
> So here are my ideal set of rules. Please adjust as you see fit:
>
> - Above all else, we recognize that consolidation is the overriding
goal.
> - We recognize that we'll all have to compromise on items we are
> passionate about, but that the overall project success is more
important.
> - This project aims to unify WebWork, Struts, Spring MVC, Beehive, and
> Spring WebFlow in to a single project that establishes clear leadership
> in the web development space.
> - All project leaders understand that once this project is releases,
> future work their own projects should cease (other than supporting it,
> minor releases, migration path to Clarity, etc).
> - Technical disputes should be coordinated by those _least_ familiar
> with the topic, and therefore least biased.
> - When criticizing or proposing alternatives or otherwise "stopping
> forward progress" - we promise to ask ourselves if this issue we're
> about to raise is really "worth it".
> - We recognize that not everyone works the way we do and we understand
> that we may have to work hard to find common ground.
>
> So what's next? Let's nail down the rules and then move on to a mission
> statement that we can announce. Remember: once we announce this,
> there's no going back, so let's spend some time on the rules and the
> mission statement. For now, please email back and forth any
> edits/additions to the rules.
>
> This is really exciting! Sorry for the long email and the (likely very)
> bureaucratic approach I'm taking with this -- I hope it adds some value.
>
> Patrick
=== Keith Donald from Spring Web Flow/MVC ===
Keith Donald wrote:
> I think a good first step is to clearly state what we all expect to
gain out
> of working together, given the dynamics of this market, and what our
> individual expectations are:
>
> Here's my take:
> --------------
> If you look at the open source web framework market, I see these camps:
>
> 1. Action-centric (Struts Classic, Struts Ti, Spring MVC, WW, SWF,
Beehive)
> 2. Component-centric (JSF-based <Struts Shale, JBoss Seam>, Tapestry,
> Wicket, Echo)
> 3. Ruby on Rails
>
> Options in camps #2 and #3 represent considerable more shock to adopt
than
> those in #1. This is for various reasons, but mainly because the
majority
> of the market (existing Struts users) can more naturally migrate to the
> other action-centric frameworks. Spring MVC, for example, has been
> positioned as a more extensible Struts and that strategy has proven
fairly
> effective. Spring Web Flow, is usable as a component from within both
> Struts classic and Spring MVC, and that too has proven effective.
Beehive
> is built on Struts.
>
> So there is definite overlap (and some compliment, too) between Struts,
> Spring MVC, WW, SWF, and Beehive, and I think it's fair to say we share
> similar goals for tackling the same problems. Because of this, there
is a
> natural fit for consolidation/collaboration, motivated more now by two
> external forces:
>
> 1. Camps #2 and #3 are threats. RoR is one, JBoss Seam is another.
>
> 2. The market is fragmented, and that creates user confusion. There
is no
> clear "next paradigm" <is JSF the base for that or not?>, and that
creates
> (encourages?) opportunity for new entrants with little invested thus
far to
> jump in and steal the show (look what Seam is trying to do, and the
RoR hype
> coming from high-profile independents in the Java community).
>
> --
>
> So the "clarity" project in my mind should be about providing a clear
"next"
> choice in the web-space for the Struts Classic, TI, WW, Beehive, and
Spring
> communities, with the premise being we'd be a lot stronger together
than we
> would competing with one another in essentially similar (but slightly
> different) ways.
>
> From my perspective, I think it's important to market a full-stack
product,
> "clarity", which unites our respective brands/technologies; however,
I feel
> it's just as important that such a stack be built from a set of
> best-of-breed components that lends itself to choice. For example, we
> wouldn't want to just ignore JSF, it's not going away (and that is
exactly
> why Spring has made JSF integration a high priority, integrating SWF as a
> more powerful JSF NavigationHandler).
>
> The ultimate goal, though, would be to win on the full-stack, the
"clarity"
> brand, appealing to a message of simplicity comparable to RoR but without
> the shock.
>
> Interface21 would be willing to fund marketing and technical effort
behind
> this (including hosting infrastructure), hopefully with the support
of BEA
> as well.
>
> --
>
> From Spring's perspective there are a couple of expectations/issues I
want
> to get out there:
>
> - Spring in general has moved from being the gem of the technology
> enthusiasts to more of a rock for the pragmatists (early majority).
This is
> more of the case for Spring's middle ware stack (IoC/TX/DAO/etc), but
Spring
> MVC also applies to some degree as it is shipped with the core framework.
> Among other things, this means Interface21 and BEA are now in the
business
> of providing Spring support/training/certification, and that entails
> contractual obligations for supporting existing versions of Spring.
So work
> on any part of the framework just can't stop on a dime: we must
continue to
> support our customers. Backwards compatibility, as well as the
ability to
> run on existing infrastructure <JDK 1.3 or >), is very important to
us for
> this reason.
>
> With that said, however, we do expect more support work around Spring's
> middle ware stack, as it is more widely used than Spring MVC. So we
do have
> more flexibility for change with Spring MVC, but we just can't stop
> supporting it. Likewise, we'd want a "clarity" migration from Spring
MVC to
> be as easy as possible.
>
> I think ease of adoption is important to all of us, else our own
communities
> may turn on us.
>
> - Spring Web Flow represents a major investment for us in the last year.
> We've put much more resources into SWF than we have MVC, as MVC has
always
> been a foundation to build on while SWF is a full-featured page flow
> product. SWF is also at a different place in the market than MVC: as
a new
> product positioned as a breakthrough technology, it is the gem of the
> enthusiast at this point. We expect when it reaches 1.0 it will become
> widely adopted quickly, as it has considerable momentum now, and is well
> positioned.
>
> Given that, I see opportunity with Clarity to capitalize on synergy
between
> SWF and Beehive PF and also leverage the momentum of SWF's
approaching 1.0
> release. I do have concerns of dilution: we wouldn't want to dilute the
> effort/branding we've put into SWF, and risk losing the momentum we
have now
> (or worse, giving it away to say JBoss Seam, who is trying to play
catchup
> with both of us).
>
> What I'm saying is SWF is going to be successful on its own, as a new
> product addressing an untapped niche, so we want to make sure we take
> advantage of that with Clarity without dilution... and do so quickly,
before
> other competitors have a chance to stake a claim by copying it and making
> the clone a part of their "full stack".
>
> --
>
> I hope this provides some insight into where Spring is coming from
and our
> interest with Clarity. I feel this is unique opportunity to come
together
> and leverage the best in each of our respective products, and unite our
> communities under a common brand whose development is sustained not
only by
> open source developers but commercial companies such as Interface21
and BEA
> as well.
>
> Once we have it out in the open what we all hope to gain, I think a good
> next step is to start flushing out from a technical perspective what this
> thing would look like--in the ideal, and keeping in mind migration
from our
> existing products, and the need for components at each key part in the
> stack. Once the technical architecture is understood, then I think it's
> natural to start focusing on marketing/branding.
>
> Keith
>
> -----Original Message-----
> From: Patrick Lightbody [mailto:plightbo@gmail.com]
> Sent: Thursday, October 06, 2005 11:20 AM
> To: Rich Feit
> Cc: Keith Donald; Don Brown; Jason Carreira
> Subject: Re: Project Clarity Kickoff
>
> Rich,
> Yes, the project of course would be open source and likely Apache 2.0
> License.
>
> I agree: Our mission statement must give a high level detail of the
> project as well, clarifying the space.
>
> I also think the wikis/infrastructure should be open.
>
> As for technical details (step #4), when we get there we will
> definitely focus on framework features and characterization. I just
> don't want to dive in to these things yet - as some topics can and
> will be very contentious. That's why I'm avoiding a reply to Jason's
> email :)
>
> You're right -- that rule about "stopping the other projects" is
> simply there to make sure that we all understand that competing
> efforts would be ramped down. I think we all know that, so it may not
> even be worth stating.
>
> Patrick
>
> On Oct 6, 2005, at 12:21 AM, Rich Feit wrote:
>
>
>>Patrick,
>>
>>This *is* really exciting -- if Clarity comes about, it'll cut through
>>the confusion that's starting to dominate this space.
>>
>>I think you're setting this up really well. I have a few specific
>>comments, but my first is this: before I could commit Beehive to the
>>project, I have to be able to share it with the Beehive community,
>>even
>>at this early stage. Some kind of message that says a bunch of key
>>projects want to consolidate to eliminate overlap, and that this would
>>supplant a chunk of Beehive. Committers vote, possibly tell me to
>>go to
>>hell. I assume this isn't a problem, but I want to make sure it's out
>>there. (Don, I guess you're in the same boat...?)
>>
>>Some specifics inline...
>>
>>Patrick Lightbody wrote:
>>
>>
>>
>>>(Warning: long email ahead. Don't worry, this isn't usually my style
>>>and I'll stick to brief emails moving forward.)
>>>
>>>Hey guys -- this is the official "kickoff" of the project we've all
>>>been talking about. Keith had a great code name for the project:
>>>Clarity.
>>>
>>>Before I get started, I just wanted to clarify the following people
>>>involved and what their roles are:
>>>
>>> - Keith represents the Spring team, including the Spring MVC and
>>>Spring WebFlow process. For now he will handle all the communication
>>>between this project and the rest of the Spring folks.
>>> - Jason is the primary technical representative from the WebWork
>>>team. While I can add some info, I expect Jason will offer most of
>>>the technical thoughts. Jason uses Spring and has a lot to offer
>>>here.
>>> - Don Brown is a Struts committer and represents the Struts team
>>>(or
>>>at least some of them). Don is the force behind Struts Ti and can
>>>provide a lot of insight as user of WebWork and XWork, with both a
>>>Struts and simplified "flavor" to it.
>>> - Rich represents the Beehive team and also works on the Struts Ti
>>>project. Rich will represent most of the Beehive input.
>>> - Finally, I hope to, more than anything, act as a facilitator for
>>>this whole project. Obviously I have a WebWork-slanted perspective,
>>>but I believe that facilitating this process is more important than
>>>any set of features or implementations choices.
>>>
>>>As I mentioned to you guys individually, I think the best way to move
>>>forward is to take the following steps. I've taken a stab at the
>>>first item as well.
>>>
>>>
>>
>> 0) Agree on the software license. Without the right license
>>(ASF),
>>I'm guessing many of us wouldn't be able to participate.
>>
>>Also, a basic question. Is this an open source project?
>>
>>
>>
>>>1) Establish the rules: a small, agreed upon list of rules that we
>>>promise to adhere to while working on this project. These will be
>>>especially important in the early phases.
>>>
>>>1) Complete a statement: we need to come up with a single paragraph
>>>that sums up this effort. It should include the desire to work
>>>together, the desire for clarity in the java web space, and the
>>>desire to move beyond "petty" differences about implementation
>>>choices. In short, this mission statement, when releases as a press
>>>release to the entire community, should be powerful enough to get
>>>everyone excited about it and know for sure that _this_ is the effort
>>>that will bring web development productivity back to the Java camp.
>>>
>>>
>>
>>Totally. The only thing I'd add here (maybe obvious) is that this
>>should go beyond the desire to work together and bring clarity to the
>>space -- some high-level characterization of what the framework itself
>>is about.
>>
>>
>>
>>>2) Announce the project: we need to gather excitement around this as
>>>soon as possible. Doing so will not only get us early feedback from
>>>the community, it will most likely stave off a few more web
>>>frameworks from being created (I found two more just today - eek!).
>>>
>>>3) Set up a neutral place to host the project, including SVN, wiki,
>>>bug tracker, etc. This place must be detached from Jakarta/Struts,
>>>Spring, and OpenSymphony and must stay that way until we all feel
>>>comfortable working together. That will likely happen about half way
>>>through step 4...
>>>
>>>
>>
>>It would be as open as the wikis, mailing lists, repositories, etc. of
>>the rest of the projects, right?
>>
>> [additional item -- maybe falls under #4] Agree on general features
>>and characteristics of the framework. Some examples (note: I'm not
>>assuming everyone would agree to these particular ones :) ):
>> - support entities that are flow controllers as first class
>>citizens
>> - support the association of per-user state with a flow controller
>> - allow Java 5 annotations as a way to configure controllers
>> - provide a fast no-redeploy iterative dev experience
>>
>> [additional item -- maybe falls under #4] Mock up some files/
>>artifacts
>>as the user would see/write them. Like what Don did early on in Ti
>>(http://wiki.apache.org/struts/StrutsTi/ControllerMock ).
>>
>>
>>
>>
>>>4) Now for the hard part: map out a technical implementation.
>>>
>>>5) Release and re-establish Java as the place to build web
>>>applications. I hope for this to happen within 8-12 months time,
>>>starting today.
>>>
>>>So here are my ideal set of rules. Please adjust as you see fit:
>>>
>>> - Above all else, we recognize that consolidation is the overriding
>>>goal.
>>> - We recognize that we'll all have to compromise on items we are
>>>passionate about, but that the overall project success is more
>>>important.
>>> - This project aims to unify WebWork, Struts, Spring MVC, Beehive,
>>>and Spring WebFlow in to a single project that establishes clear
>>>leadership in the web development space.
>>> - All project leaders understand that once this project is
>>>releases,
>>>future work their own projects should cease (other than supporting
>>>it, minor releases, migration path to Clarity, etc).
>>> - Technical disputes should be coordinated by those _least_
>>>familiar
>>>with the topic, and therefore least biased.
>>> - When criticizing or proposing alternatives or otherwise "stopping
>>>forward progress" - we promise to ask ourselves if this issue we're
>>>about to raise is really "worth it".
>>> - We recognize that not everyone works the way we do and we
>>>understand that we may have to work hard to find common ground.
>>>
>>>
>>
>> The rules... I agree, for us to succeed, we need these. We'll all
>>have to take as a prime goal compromise/progress over dogma. My main
>>comment is about consolidation and ceasing development on the ancestor
>>projects. Beehive has components that I assume are far outside the
>>mission of Clarity (e.g., JSR 181 Web Services Metadata
>>implementation). Just want to make sure we're not trumpeting the
>>death
>>of entire frameworks that don't overlap. Relatedly, I feel that the
>>cease-development clause should go something like this:
>> "... will cease developing features that overlap with features
>>in Clarity."
>> It's clearly not in the interest of any project to keep plugging
>>along with a redundant framework (c'mon, how can you compete with
>>Clarity? :) ), but I imagine that many features will fall outside the
>>scope of what's done here.
>>
>>A final question: would people agree that we should start core/focused
>>(e.g., controller tier, view agnostic, not trying to define an entire
>>stack)? Seems like this is something that would help us move forward
>>more quickly, and would prevent us from trying to make too many leaf
>>nodes part of the trunk.
>>
>>
>>
>>>So what's next? Let's nail down the rules and then move on to a
>>>mission statement that we can announce. Remember: once we announce
>>>this, there's no going back, so let's spend some time on the rules
>>>and the mission statement. For now, please email back and forth any
>>>edits/additions to the rules.
>>>
>>>This is really exciting! Sorry for the long email and the (likely
>>>very) bureaucratic approach I'm taking with this -- I hope it adds
>>>some value.
>>>
>>>Patrick
>>>
>>>
>>
>>Exciting stuff!
>>
>>Rich
>>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Web Framework Consolidation
Posted by Ted Husted <te...@gmail.com>.
Don,
Since heavily quoted email messages can be difficult to read, and easy
to misunderstand, I've taken the liberty of formatting these messages
as wiki pages.
* http://opensource2.atlassian.com/confluence/oss/display/STRUTS/Clarity
If this is a problem for anyone, I'll take the pages down.
-Ted.
On 10/10/05, Don Brown <mr...@twdata.org> wrote:
> Consolidation is a relatively unknown concept in the crowded web
> framework space. While most frameworks are open source allowing
> cross-pollination, collaboration is still rare resulting in duplicated
> efforts and confusion for the end user. Struts Ti, a next-gen project
> in the Struts sandbox, tried to buck the trend by building on WebWork
> rather than wasting its time writing yet another Model2 framework.
>
> Taking this level of cooperation to the next level, developers from four
> popular web frameworks - Struts, Spring, WebWork, and Beehive, have
> gotten together to discuss the possibility of consolidating their
> efforts into a new project, termed Clarity. Clarity would be an
> action-based MVC framework that combines the commonality of the four
> aforementioned frameworks into one that can be built upon by all.
>
> These discussions have just began, and while no one has "officially"
> signed on, I thought I should bring it before the Struts community for
> feedback. There is still much to work out, but I want to keep the
> community involved from the beginning.
>
> I personally am excited about this project and think it will be
> beneficial to users and developers alike. The Struts Classic code base
> is showing its age, but speaking as a developer who maintains old Struts
> apps, few people have the time and budget to rewrite them from scratch
> with a more disparate framework like Shale or Wicket. I think Clarity
> would be a much easier migration for existing Struts applications and
> developers, yet support key standards like Portlets and JSF.
>
> Attached is two messages in a private email thread between Patrick
> Lightbody (WebWork), Keith Donald (Spring), Rich Feit (Beehive), and me,
> that started the Clarity discussion. We plan to have a public email
> list for Clarity discussion, but it hasn't been setup yet.
>
> What I'm looking for from the Struts community is if you think this is a
> good idea, and if you do, what we need to do to make it work.
> Personally, I don't expect Struts or even Struts Classic going away at
> all even if we agreed Clarity is migration path, so this isn't an
> either/or discussion.
>
> Again, this is _NOT_ a project announcement meant for the world, only
> the beginning of a discussion about the idea of consolidating a few web
> frameworks and how Struts fits in with this. Looking forward to the
> comments,
>
> Don
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Web Framework Consolidation
Posted by Michael Jouravlev <jm...@gmail.com>.
Away with all your superstitions,
Servile masses, arise, arise!
We'll change henceforth the old tradition,
And spurn the dust to win the prize!
On 10/10/05, Don Brown <mr...@twdata.org> wrote:
> Consolidation is a relatively unknown concept in the crowded web
> framework space. While most frameworks are open source allowing
> cross-pollination, collaboration is still rare resulting in duplicated
> efforts and confusion for the end user. Struts Ti, a next-gen project
> in the Struts sandbox, tried to buck the trend by building on WebWork
> rather than wasting its time writing yet another Model2 framework.
>
> Taking this level of cooperation to the next level, developers from four
> popular web frameworks - Struts, Spring, WebWork, and Beehive, have
> gotten together to discuss the possibility of consolidating their
> efforts into a new project, termed Clarity. Clarity would be an
> action-based MVC framework that combines the commonality of the four
> aforementioned frameworks into one that can be built upon by all.
<trimmed>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Web Framework Consolidation
Posted by Ted Husted <te...@gmail.com>.
On 10/10/05, Frank W. Zammetti <fz...@omnytex.com> wrote:
> Some people seem to believe that Struts is obsolete, or is rapidly
> becoming so, is showing it's age, etc. I believe this is only the case,
> if in fact it is, because it has been allowed to stagnate a bit in terms
> of truly evolving. It has been on autopilot for way too long and other
> frameworks have had a chance to pass it by.
It's not so much that we are on autopilot. It's that the project
velocity is glacial, and it has always been glacial. Struts 1.3 will
be our fourth release series. We've consistently averaged twenty
months between series, and it looks like 1.3 will be no exception.
Of course, some projects release more often. One reason for that is
that many other frameworks and projects have support from corporate
developers. Spring, Subversion, Geronimo, Tomcat, JBoss, to name a
few, all get a boost from volunteers who work on the project as part
of their regular jobs. The Struts Validator was developed as an
extension for a public website, and then donated to Apache, but that's
about as close as we've ever come to corporate support.
In regard to another Apache project, recently I was talking with the
"Open Source Evangelist" for a (very) large corporation about a code
they would like to donate and how to integrate volunteer corporate
developers into an Apache project. When we had concluded our other
business, I mentioned that Struts could always use some help too. He
seemed positively startled by the idea, even though this corporation
uses Struts as the foundation for their web application toolset.
So, we trudge. Hoo-hah.
Of course, we've also always depended on external extensions to fill
in the gaps. I think most of us consider projects like Struts Console,
Struts Layout (and/or DisplayTag), SSL Ext, Struts Menu, and Struts
TestCase, all to be part of the quintessential.Struts stack, not to
mention some of the newcomers, like Java Web Parts, Struts Dialog, and
FormDef.
* http://www.jamesholmes.com/struts/console/
* http://struts.application-servers.com/
* http://displaytag.sourceforge.net/
* http://sslext.sourceforge.net/
* http://struts-menu.sourceforge.net/
* http://strutstestcase.sourceforge.net/
* http://javawebparts.sourceforge.net/
* http://struts.sourceforge.net/strutsdialogs/index.html
* https://formdef.dev.java.net/
-- Ted.
http://www.husted.com/poe/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Web Framework Consolidation
Posted by Dakota Jack <da...@gmail.com>.
I guess if you don't mind having a pile of controllers in an MVC
environment and don't having leaky abstractions abounding in your
code, this would work. Myself, I like to KISS and do not like leaky
abstractions.
On 10/19/05, Rich Feit <ri...@gmail.com> wrote:
> JSF (or any framework that supports serverside component/event-based
> pages and which is pluggable enough) is not incompatible with an
> action-based controller like Struts. To use them together, you let your
> JSF pages handle intra-page interactions (possibly spanning multiple
> requests) and then raise actions on the controller to navigate to other
> pages (and to run app-level code that your pages shouldn't know about).
> It fits nicely, and in a lot of ways it's like using JSP as your view
> tier... only with much more capable pages.
>
> Rich
>
> Dakota Jack wrote:
>
> >Bolting JSF onto Struts makes no sense. They are simply incompatible.
> > If you want to do something with the merits of both, you still have
> >to choose which way you want to go. You cannot go both ways, unless
> >you are doing it just to fish people in.
> >
> >On 10/10/05, Frank W. Zammetti <fz...@omnytex.com> wrote:
> >
> >
> >>Just a few opinions from the peanut gallery...
> >>
> >>The era of the "classic" webapp is dead. Any new framework that doesn't
> >>make it easy (well, EASIER anyway) to develop robust RIAs is dead on
> >>arrival as far as I am concerned.
> >>
> >>Further, I do not believe that the action-centric and component-centric
> >>models need be exclusive of each other and in fact I believe that is the
> >>natural evolution of things. I don't think this necessarily implies an
> >>approach like bolting JSF onto Struts for example, but then again maybe
> >>that is the most natural path. The real point though is the merging of
> >>the two approaches into *something*, whatever that something winds up being.
> >>
> >>So, if Clarity is going to take into consideration the building of RIAs
> >>at its core, than I for one will be interested in how it evolves. IF
> >>that isn't a central theme though, then it's DOA from my perspective.
> >>
> >>All of the frameworks involved do many things right, so it would seem
> >>logical to me that as long as you choose the things that work to merge,
> >>the end result should be pretty good. I would start by getting input
> >>from the community on what aspects of the contributing frameworks they
> >>feel truly work and are must-haves for a next-generation framework.
> >>Heck, the results of such a question could wind up being your goal
> >>statement entirely :)
> >>
> >>I would also make the point that Struts is the market leader for good
> >>reason and so I would hope it isn't the fourth banana in the group.
> >>Some people seem to believe that Struts is obsolete, or is rapidly
> >>becoming so, is showing it's age, etc. I believe this is only the case,
> >>if in fact it is, because it has been allowed to stagnate a bit in terms
> >>of truly evolving. It has been on autopilot for way too long and other
> >>frameworks have had a chance to pass it by. Be that as it may, the
> >>point is that I believe for a new framework to be successful it should
> >>take more cues from Struts on what TO do rather than what NOT to do.
> >>Anything less is, IMO, foolishly ignoring the reputation and community
> >>and success that Struts has enjoyed.
> >>
> >>Those are my initial thoughts. In any case, I offer my sincerest Good
> >>Luck in the endeavor, I'll be interested to see how it goes.
> >>
> >>--
> >>Frank W. Zammetti
> >>Founder and Chief Software Architect
> >>Omnytex Technologies
> >>http://www.omnytex.com
> >>AIM: fzammetti
> >>Yahoo: fzammetti
> >>MSN: fzammetti@hotmail.com
> >>
> >>Don Brown wrote:
> >>
> >>
> >>>Consolidation is a relatively unknown concept in the crowded web
> >>>framework space. While most frameworks are open source allowing
> >>>cross-pollination, collaboration is still rare resulting in duplicated
> >>>efforts and confusion for the end user. Struts Ti, a next-gen project
> >>>in the Struts sandbox, tried to buck the trend by building on WebWork
> >>>rather than wasting its time writing yet another Model2 framework.
> >>>
> >>>Taking this level of cooperation to the next level, developers from four
> >>>popular web frameworks - Struts, Spring, WebWork, and Beehive, have
> >>>gotten together to discuss the possibility of consolidating their
> >>>efforts into a new project, termed Clarity. Clarity would be an
> >>>action-based MVC framework that combines the commonality of the four
> >>>aforementioned frameworks into one that can be built upon by all.
> >>>
> >>>These discussions have just began, and while no one has "officially"
> >>>signed on, I thought I should bring it before the Struts community for
> >>>feedback. There is still much to work out, but I want to keep the
> >>>community involved from the beginning.
> >>>
> >>>I personally am excited about this project and think it will be
> >>>beneficial to users and developers alike. The Struts Classic code base
> >>>is showing its age, but speaking as a developer who maintains old Struts
> >>>apps, few people have the time and budget to rewrite them from scratch
> >>>with a more disparate framework like Shale or Wicket. I think Clarity
> >>>would be a much easier migration for existing Struts applications and
> >>>developers, yet support key standards like Portlets and JSF.
> >>>
> >>>Attached is two messages in a private email thread between Patrick
> >>>Lightbody (WebWork), Keith Donald (Spring), Rich Feit (Beehive), and me,
> >>>that started the Clarity discussion. We plan to have a public email
> >>>list for Clarity discussion, but it hasn't been setup yet.
> >>>
> >>>What I'm looking for from the Struts community is if you think this is a
> >>>good idea, and if you do, what we need to do to make it work.
> >>>Personally, I don't expect Struts or even Struts Classic going away at
> >>>all even if we agreed Clarity is migration path, so this isn't an
> >>>either/or discussion.
> >>>
> >>>Again, this is _NOT_ a project announcement meant for the world, only
> >>>the beginning of a discussion about the idea of consolidating a few web
> >>>frameworks and how Struts fits in with this. Looking forward to the
> >>>comments,
> >>>
> >>>Don
> >>>
> >>>=== Initial kickoff by Patrick Lightbody from WebWork ===
> >>>Patrick Lightbody wrote:
> >>> > (Warning: long email ahead. Don't worry, this isn't usually my style
> >>> > and I'll stick to brief emails moving forward.)
> >>> >
> >>> > Hey guys -- this is the official "kickoff" of the project we've all
> >>> > been talking about. Keith had a great code name for the project:
> >>>Clarity.
> >>> >
> >>> > Before I get started, I just wanted to clarify the following people
> >>> > involved and what their roles are:
> >>> >
> >>> > - Keith represents the Spring team, including the Spring MVC and
> >>> > Spring WebFlow process. For now he will handle all the communication
> >>> > between this project and the rest of the Spring folks.
> >>> > - Jason is the primary technical representative from the WebWork team.
> >>> > While I can add some info, I expect Jason will offer most of the
> >>> > technical thoughts. Jason uses Spring and has a lot to offer here.
> >>> > - Don Brown is a Struts committer and represents the Struts team (or
> >>> > at least some of them). Don is the force behind Struts Ti and can
> >>> > provide a lot of insight as user of WebWork and XWork, with both a
> >>> > Struts and simplified "flavor" to it.
> >>> > - Rich represents the Beehive team and also works on the Struts Ti
> >>> > project. Rich will represent most of the Beehive input.
> >>> > - Finally, I hope to, more than anything, act as a facilitator for
> >>> > this whole project. Obviously I have a WebWork-slanted perspective, but
> >>> > I believe that facilitating this process is more important than any set
> >>> > of features or implementations choices.
> >>> >
> >>> > As I mentioned to you guys individually, I think the best way to move
> >>> > forward is to take the following steps. I've taken a stab at the first
> >>> > item as well.
> >>> >
> >>> > 1) Establish the rules: a small, agreed upon list of rules that we
> >>> > promise to adhere to while working on this project. These will be
> >>> > especially important in the early phases.
> >>> >
> >>> > 1) Complete a statement: we need to come up with a single paragraph
> >>> > that sums up this effort. It should include the desire to work
> >>> > together, the desire for clarity in the java web space, and the desire
> >>> > to move beyond "petty" differences about implementation choices. In
> >>> > short, this mission statement, when releases as a press release to the
> >>> > entire community, should be powerful enough to get everyone excited
> >>> > about it and know for sure that _this_ is the effort that will bring
> >>> > web development productivity back to the Java camp.
> >>> >
> >>> > 2) Announce the project: we need to gather excitement around this as
> >>> > soon as possible. Doing so will not only get us early feedback from the
> >>> > community, it will most likely stave off a few more web frameworks from
> >>> > being created (I found two more just today - eek!).
> >>> >
> >>> > 3) Set up a neutral place to host the project, including SVN, wiki, bug
> >>> > tracker, etc. This place must be detached from Jakarta/Struts, Spring,
> >>> > and OpenSymphony and must stay that way until we all feel comfortable
> >>> > working together. That will likely happen about half way through
> >>>step 4...
> >>> >
> >>> > 4) Now for the hard part: map out a technical implementation.
> >>> >
> >>> > 5) Release and re-establish Java as the place to build web
> >>> > applications. I hope for this to happen within 8-12 months time,
> >>> > starting today.
> >>> >
> >>> > So here are my ideal set of rules. Please adjust as you see fit:
> >>> >
> >>> > - Above all else, we recognize that consolidation is the overriding
> >>> goal.
> >>> > - We recognize that we'll all have to compromise on items we are
> >>> > passionate about, but that the overall project success is more
> >>>important.
> >>> > - This project aims to unify WebWork, Struts, Spring MVC, Beehive, and
> >>> > Spring WebFlow in to a single project that establishes clear leadership
> >>> > in the web development space.
> >>> > - All project leaders understand that once this project is releases,
> >>> > future work their own projects should cease (other than supporting it,
> >>> > minor releases, migration path to Clarity, etc).
> >>> > - Technical disputes should be coordinated by those _least_ familiar
> >>> > with the topic, and therefore least biased.
> >>> > - When criticizing or proposing alternatives or otherwise "stopping
> >>> > forward progress" - we promise to ask ourselves if this issue we're
> >>> > about to raise is really "worth it".
> >>> > - We recognize that not everyone works the way we do and we understand
> >>> > that we may have to work hard to find common ground.
> >>> >
> >>> > So what's next? Let's nail down the rules and then move on to a mission
> >>> > statement that we can announce. Remember: once we announce this,
> >>> > there's no going back, so let's spend some time on the rules and the
> >>> > mission statement. For now, please email back and forth any
> >>> > edits/additions to the rules.
> >>> >
> >>> > This is really exciting! Sorry for the long email and the (likely very)
> >>> > bureaucratic approach I'm taking with this -- I hope it adds some
> >>>value.
> >>> >
> >>> > Patrick
> >>>
> >>>=== Keith Donald from Spring Web Flow/MVC ===
> >>>
> >>>Keith Donald wrote:
> >>> > I think a good first step is to clearly state what we all expect to
> >>>gain out
> >>> > of working together, given the dynamics of this market, and what our
> >>> > individual expectations are:
> >>> >
> >>> > Here's my take:
> >>> > --------------
> >>> > If you look at the open source web framework market, I see these camps:
> >>> >
> >>> > 1. Action-centric (Struts Classic, Struts Ti, Spring MVC, WW, SWF,
> >>>Beehive)
> >>> > 2. Component-centric (JSF-based <Struts Shale, JBoss Seam>, Tapestry,
> >>> > Wicket, Echo)
> >>> > 3. Ruby on Rails
> >>> >
> >>> > Options in camps #2 and #3 represent considerable more shock to adopt
> >>>than
> >>> > those in #1. This is for various reasons, but mainly because the
> >>>majority
> >>> > of the market (existing Struts users) can more naturally migrate to the
> >>> > other action-centric frameworks. Spring MVC, for example, has been
> >>> > positioned as a more extensible Struts and that strategy has proven
> >>>fairly
> >>> > effective. Spring Web Flow, is usable as a component from within both
> >>> > Struts classic and Spring MVC, and that too has proven effective.
> >>>Beehive
> >>> > is built on Struts.
> >>> >
> >>> > So there is definite overlap (and some compliment, too) between Struts,
> >>> > Spring MVC, WW, SWF, and Beehive, and I think it's fair to say we share
> >>> > similar goals for tackling the same problems. Because of this, there
> >>>is a
> >>> > natural fit for consolidation/collaboration, motivated more now by two
> >>> > external forces:
> >>> >
> >>> > 1. Camps #2 and #3 are threats. RoR is one, JBoss Seam is another.
> >>> >
> >>> > 2. The market is fragmented, and that creates user confusion. There
> >>>is no
> >>> > clear "next paradigm" <is JSF the base for that or not?>, and that
> >>>creates
> >>> > (encourages?) opportunity for new entrants with little invested thus
> >>>far to
> >>> > jump in and steal the show (look what Seam is trying to do, and the
> >>>RoR hype
> >>> > coming from high-profile independents in the Java community).
> >>> >
> >>> > --
> >>> >
> >>> > So the "clarity" project in my mind should be about providing a clear
> >>>"next"
> >>> > choice in the web-space for the Struts Classic, TI, WW, Beehive, and
> >>>Spring
> >>> > communities, with the premise being we'd be a lot stronger together
> >>>than we
> >>> > would competing with one another in essentially similar (but slightly
> >>> > different) ways.
> >>> >
> >>> > From my perspective, I think it's important to market a full-stack
> >>>product,
> >>> > "clarity", which unites our respective brands/technologies; however,
> >>>I feel
> >>> > it's just as important that such a stack be built from a set of
> >>> > best-of-breed components that lends itself to choice. For example, we
> >>> > wouldn't want to just ignore JSF, it's not going away (and that is
> >>>exactly
> >>> > why Spring has made JSF integration a high priority, integrating SWF
> >>>as a
> >>> > more powerful JSF NavigationHandler).
> >>> >
> >>> > The ultimate goal, though, would be to win on the full-stack, the
> >>>"clarity"
> >>> > brand, appealing to a message of simplicity comparable to RoR but
> >>>without
> >>> > the shock.
> >>> >
> >>> > Interface21 would be willing to fund marketing and technical effort
> >>>behind
> >>> > this (including hosting infrastructure), hopefully with the support
> >>>of BEA
> >>> > as well.
> >>> >
> >>> > --
> >>> >
> >>> > From Spring's perspective there are a couple of expectations/issues I
> >>>want
> >>> > to get out there:
> >>> >
> >>> > - Spring in general has moved from being the gem of the technology
> >>> > enthusiasts to more of a rock for the pragmatists (early majority).
> >>>This is
> >>> > more of the case for Spring's middle ware stack (IoC/TX/DAO/etc), but
> >>>Spring
> >>> > MVC also applies to some degree as it is shipped with the core
> >>>framework.
> >>> > Among other things, this means Interface21 and BEA are now in the
> >>>business
> >>> > of providing Spring support/training/certification, and that entails
> >>> > contractual obligations for supporting existing versions of Spring.
> >>>So work
> >>> > on any part of the framework just can't stop on a dime: we must
> >>>continue to
> >>> > support our customers. Backwards compatibility, as well as the
> >>>ability to
> >>> > run on existing infrastructure <JDK 1.3 or >), is very important to
> >>>us for
> >>> > this reason.
> >>> >
> >>> > With that said, however, we do expect more support work around Spring's
> >>> > middle ware stack, as it is more widely used than Spring MVC. So we
> >>>do have
> >>> > more flexibility for change with Spring MVC, but we just can't stop
> >>> > supporting it. Likewise, we'd want a "clarity" migration from Spring
> >>>MVC to
> >>> > be as easy as possible.
> >>> >
> >>> > I think ease of adoption is important to all of us, else our own
> >>>communities
> >>> > may turn on us.
> >>> >
> >>> > - Spring Web Flow represents a major investment for us in the last year.
> >>> > We've put much more resources into SWF than we have MVC, as MVC has
> >>>always
> >>> > been a foundation to build on while SWF is a full-featured page flow
> >>> > product. SWF is also at a different place in the market than MVC: as
> >>>a new
> >>> > product positioned as a breakthrough technology, it is the gem of the
> >>> > enthusiast at this point. We expect when it reaches 1.0 it will become
> >>> > widely adopted quickly, as it has considerable momentum now, and is well
> >>> > positioned.
> >>> >
> >>> > Given that, I see opportunity with Clarity to capitalize on synergy
> >>>between
> >>> > SWF and Beehive PF and also leverage the momentum of SWF's
> >>>approaching 1.0
> >>> > release. I do have concerns of dilution: we wouldn't want to dilute the
> >>> > effort/branding we've put into SWF, and risk losing the momentum we
> >>>have now
> >>> > (or worse, giving it away to say JBoss Seam, who is trying to play
> >>>catchup
> >>> > with both of us).
> >>> >
> >>> > What I'm saying is SWF is going to be successful on its own, as a new
> >>> > product addressing an untapped niche, so we want to make sure we take
> >>> > advantage of that with Clarity without dilution... and do so quickly,
> >>>before
> >>> > other competitors have a chance to stake a claim by copying it and
> >>>making
> >>> > the clone a part of their "full stack".
> >>> >
> >>> > --
> >>> >
> >>> > I hope this provides some insight into where Spring is coming from
> >>>and our
> >>> > interest with Clarity. I feel this is unique opportunity to come
> >>>together
> >>> > and leverage the best in each of our respective products, and unite our
> >>> > communities under a common brand whose development is sustained not
> >>>only by
> >>> > open source developers but commercial companies such as Interface21
> >>>and BEA
> >>> > as well.
> >>> >
> >>> > Once we have it out in the open what we all hope to gain, I think a good
> >>> > next step is to start flushing out from a technical perspective what
> >>>this
> >>> > thing would look like--in the ideal, and keeping in mind migration
> >>>from our
> >>> > existing products, and the need for components at each key part in the
> >>> > stack. Once the technical architecture is understood, then I think it's
> >>> > natural to start focusing on marketing/branding.
> >>> >
> >>> > Keith
> >>> >
> >>> > -----Original Message-----
> >>> > From: Patrick Lightbody [mailto:plightbo@gmail.com]
> >>> > Sent: Thursday, October 06, 2005 11:20 AM
> >>> > To: Rich Feit
> >>> > Cc: Keith Donald; Don Brown; Jason Carreira
> >>> > Subject: Re: Project Clarity Kickoff
> >>> >
> >>> > Rich,
> >>> > Yes, the project of course would be open source and likely Apache 2.0
> >>> > License.
> >>> >
> >>> > I agree: Our mission statement must give a high level detail of the
> >>> > project as well, clarifying the space.
> >>> >
> >>> > I also think the wikis/infrastructure should be open.
> >>> >
> >>> > As for technical details (step #4), when we get there we will
> >>> > definitely focus on framework features and characterization. I just
> >>> > don't want to dive in to these things yet - as some topics can and
> >>> > will be very contentious. That's why I'm avoiding a reply to Jason's
> >>> > email :)
> >>> >
> >>> > You're right -- that rule about "stopping the other projects" is
> >>> > simply there to make sure that we all understand that competing
> >>> > efforts would be ramped down. I think we all know that, so it may not
> >>> > even be worth stating.
> >>> >
> >>> > Patrick
> >>> >
> >>> > On Oct 6, 2005, at 12:21 AM, Rich Feit wrote:
> >>> >
> >>> >
> >>> >>Patrick,
> >>> >>
> >>> >>This *is* really exciting -- if Clarity comes about, it'll cut through
> >>> >>the confusion that's starting to dominate this space.
> >>> >>
> >>> >>I think you're setting this up really well. I have a few specific
> >>> >>comments, but my first is this: before I could commit Beehive to the
> >>> >>project, I have to be able to share it with the Beehive community,
> >>> >>even
> >>> >>at this early stage. Some kind of message that says a bunch of key
> >>> >>projects want to consolidate to eliminate overlap, and that this would
> >>> >>supplant a chunk of Beehive. Committers vote, possibly tell me to
> >>> >>go to
> >>> >>hell. I assume this isn't a problem, but I want to make sure it's out
> >>> >>there. (Don, I guess you're in the same boat...?)
> >>> >>
> >>> >>Some specifics inline...
> >>> >>
> >>> >>Patrick Lightbody wrote:
> >>> >>
> >>> >>
> >>> >>
> >>> >>>(Warning: long email ahead. Don't worry, this isn't usually my style
> >>> >>>and I'll stick to brief emails moving forward.)
> >>> >>>
> >>> >>>Hey guys -- this is the official "kickoff" of the project we've all
> >>> >>>been talking about. Keith had a great code name for the project:
> >>> >>>Clarity.
> >>> >>>
> >>> >>>Before I get started, I just wanted to clarify the following people
> >>> >>>involved and what their roles are:
> >>> >>>
> >>> >>> - Keith represents the Spring team, including the Spring MVC and
> >>> >>>Spring WebFlow process. For now he will handle all the communication
> >>> >>>between this project and the rest of the Spring folks.
> >>> >>> - Jason is the primary technical representative from the WebWork
> >>> >>>team. While I can add some info, I expect Jason will offer most of
> >>> >>>the technical thoughts. Jason uses Spring and has a lot to offer
> >>> >>>here.
> >>> >>> - Don Brown is a Struts committer and represents the Struts team
> >>> >>>(or
> >>> >>>at least some of them). Don is the force behind Struts Ti and can
> >>> >>>provide a lot of insight as user of WebWork and XWork, with both a
> >>> >>>Struts and simplified "flavor" to it.
> >>> >>> - Rich represents the Beehive team and also works on the Struts Ti
> >>> >>>project. Rich will represent most of the Beehive input.
> >>> >>> - Finally, I hope to, more than anything, act as a facilitator for
> >>> >>>this whole project. Obviously I have a WebWork-slanted perspective,
> >>> >>>but I believe that facilitating this process is more important than
> >>> >>>any set of features or implementations choices.
> >>> >>>
> >>> >>>As I mentioned to you guys individually, I think the best way to move
> >>> >>>forward is to take the following steps. I've taken a stab at the
> >>> >>>first item as well.
> >>> >>>
> >>> >>>
> >>> >>
> >>> >> 0) Agree on the software license. Without the right license
> >>> >>(ASF),
> >>> >>I'm guessing many of us wouldn't be able to participate.
> >>> >>
> >>> >>Also, a basic question. Is this an open source project?
> >>> >>
> >>> >>
> >>> >>
> >>> >>>1) Establish the rules: a small, agreed upon list of rules that we
> >>> >>>promise to adhere to while working on this project. These will be
> >>> >>>especially important in the early phases.
> >>> >>>
> >>> >>>1) Complete a statement: we need to come up with a single paragraph
> >>> >>>that sums up this effort. It should include the desire to work
> >>> >>>together, the desire for clarity in the java web space, and the
> >>> >>>desire to move beyond "petty" differences about implementation
> >>> >>>choices. In short, this mission statement, when releases as a press
> >>> >>>release to the entire community, should be powerful enough to get
> >>> >>>everyone excited about it and know for sure that _this_ is the effort
> >>> >>>that will bring web development productivity back to the Java camp.
> >>> >>>
> >>> >>>
> >>> >>
> >>> >>Totally. The only thing I'd add here (maybe obvious) is that this
> >>> >>should go beyond the desire to work together and bring clarity to the
> >>> >>space -- some high-level characterization of what the framework itself
> >>> >>is about.
> >>> >>
> >>> >>
> >>> >>
> >>> >>>2) Announce the project: we need to gather excitement around this as
> >>> >>>soon as possible. Doing so will not only get us early feedback from
> >>> >>>the community, it will most likely stave off a few more web
> >>> >>>frameworks from being created (I found two more just today - eek!).
> >>> >>>
> >>> >>>3) Set up a neutral place to host the project, including SVN, wiki,
> >>> >>>bug tracker, etc. This place must be detached from Jakarta/Struts,
> >>> >>>Spring, and OpenSymphony and must stay that way until we all feel
> >>> >>>comfortable working together. That will likely happen about half way
> >>> >>>through step 4...
> >>> >>>
> >>> >>>
> >>> >>
> >>> >>It would be as open as the wikis, mailing lists, repositories, etc. of
> >>> >>the rest of the projects, right?
> >>> >>
> >>> >> [additional item -- maybe falls under #4] Agree on general features
> >>> >>and characteristics of the framework. Some examples (note: I'm not
> >>> >>assuming everyone would agree to these particular ones :) ):
> >>> >> - support entities that are flow controllers as first class
> >>> >>citizens
> >>> >> - support the association of per-user state with a flow controller
> >>> >> - allow Java 5 annotations as a way to configure controllers
> >>> >> - provide a fast no-redeploy iterative dev experience
> >>> >>
> >>> >> [additional item -- maybe falls under #4] Mock up some files/
> >>> >>artifacts
> >>> >>as the user would see/write them. Like what Don did early on in Ti
> >>> >>(http://wiki.apache.org/struts/StrutsTi/ControllerMock ).
> >>> >>
> >>> >>
> >>> >>
> >>> >>
> >>> >>>4) Now for the hard part: map out a technical implementation.
> >>> >>>
> >>> >>>5) Release and re-establish Java as the place to build web
> >>> >>>applications. I hope for this to happen within 8-12 months time,
> >>> >>>starting today.
> >>> >>>
> >>> >>>So here are my ideal set of rules. Please adjust as you see fit:
> >>> >>>
> >>> >>> - Above all else, we recognize that consolidation is the overriding
> >>> >>>goal.
> >>> >>> - We recognize that we'll all have to compromise on items we are
> >>> >>>passionate about, but that the overall project success is more
> >>> >>>important.
> >>> >>> - This project aims to unify WebWork, Struts, Spring MVC, Beehive,
> >>> >>>and Spring WebFlow in to a single project that establishes clear
> >>> >>>leadership in the web development space.
> >>> >>> - All project leaders understand that once this project is
> >>> >>>releases,
> >>> >>>future work their own projects should cease (other than supporting
> >>> >>>it, minor releases, migration path to Clarity, etc).
> >>> >>> - Technical disputes should be coordinated by those _least_
> >>> >>>familiar
> >>> >>>with the topic, and therefore least biased.
> >>> >>> - When criticizing or proposing alternatives or otherwise "stopping
> >>> >>>forward progress" - we promise to ask ourselves if this issue we're
> >>> >>>about to raise is really "worth it".
> >>> >>> - We recognize that not everyone works the way we do and we
> >>> >>>understand that we may have to work hard to find common ground.
> >>> >>>
> >>> >>>
> >>> >>
> >>> >> The rules... I agree, for us to succeed, we need these. We'll all
> >>> >>have to take as a prime goal compromise/progress over dogma. My main
> >>> >>comment is about consolidation and ceasing development on the ancestor
> >>> >>projects. Beehive has components that I assume are far outside the
> >>> >>mission of Clarity (e.g., JSR 181 Web Services Metadata
> >>> >>implementation). Just want to make sure we're not trumpeting the
> >>> >>death
> >>> >>of entire frameworks that don't overlap. Relatedly, I feel that the
> >>> >>cease-development clause should go something like this:
> >>> >> "... will cease developing features that overlap with features
> >>> >>in Clarity."
> >>> >> It's clearly not in the interest of any project to keep plugging
> >>> >>along with a redundant framework (c'mon, how can you compete with
> >>> >>Clarity? :) ), but I imagine that many features will fall outside the
> >>> >>scope of what's done here.
> >>> >>
> >>> >>A final question: would people agree that we should start core/focused
> >>> >>(e.g., controller tier, view agnostic, not trying to define an entire
> >>> >>stack)? Seems like this is something that would help us move forward
> >>> >>more quickly, and would prevent us from trying to make too many leaf
> >>> >>nodes part of the trunk.
> >>> >>
> >>> >>
> >>> >>
> >>> >>>So what's next? Let's nail down the rules and then move on to a
> >>> >>>mission statement that we can announce. Remember: once we announce
> >>> >>>this, there's no going back, so let's spend some time on the rules
> >>> >>>and the mission statement. For now, please email back and forth any
> >>> >>>edits/additions to the rules.
> >>> >>>
> >>> >>>This is really exciting! Sorry for the long email and the (likely
> >>> >>>very) bureaucratic approach I'm taking with this -- I hope it adds
> >>> >>>some value.
> >>> >>>
> >>> >>>Patrick
> >>> >>>
> >>> >>>
> >>> >>
> >>> >>Exciting stuff!
> >>> >>
> >>> >>Rich
> >>> >>
> >>> >
> >>> >
> >>> >
> >>>
> >>>
> >>>
> >>>
> >>>---------------------------------------------------------------------
> >>>To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >>>For additional commands, e-mail: dev-help@struts.apache.org
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >>For additional commands, e-mail: dev-help@struts.apache.org
> >>
> >>
> >>
> >>
> >
> >
> >--
> >"You can lead a horse to water but you cannot make it float on its back."
> >~Dakota Jack~
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >For additional commands, e-mail: dev-help@struts.apache.org
> >
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Web Framework Consolidation
Posted by Rich Feit <ri...@gmail.com>.
JSF (or any framework that supports serverside component/event-based
pages and which is pluggable enough) is not incompatible with an
action-based controller like Struts. To use them together, you let your
JSF pages handle intra-page interactions (possibly spanning multiple
requests) and then raise actions on the controller to navigate to other
pages (and to run app-level code that your pages shouldn't know about).
It fits nicely, and in a lot of ways it's like using JSP as your view
tier... only with much more capable pages.
Rich
Dakota Jack wrote:
>Bolting JSF onto Struts makes no sense. They are simply incompatible.
> If you want to do something with the merits of both, you still have
>to choose which way you want to go. You cannot go both ways, unless
>you are doing it just to fish people in.
>
>On 10/10/05, Frank W. Zammetti <fz...@omnytex.com> wrote:
>
>
>>Just a few opinions from the peanut gallery...
>>
>>The era of the "classic" webapp is dead. Any new framework that doesn't
>>make it easy (well, EASIER anyway) to develop robust RIAs is dead on
>>arrival as far as I am concerned.
>>
>>Further, I do not believe that the action-centric and component-centric
>>models need be exclusive of each other and in fact I believe that is the
>>natural evolution of things. I don't think this necessarily implies an
>>approach like bolting JSF onto Struts for example, but then again maybe
>>that is the most natural path. The real point though is the merging of
>>the two approaches into *something*, whatever that something winds up being.
>>
>>So, if Clarity is going to take into consideration the building of RIAs
>>at its core, than I for one will be interested in how it evolves. IF
>>that isn't a central theme though, then it's DOA from my perspective.
>>
>>All of the frameworks involved do many things right, so it would seem
>>logical to me that as long as you choose the things that work to merge,
>>the end result should be pretty good. I would start by getting input
>>from the community on what aspects of the contributing frameworks they
>>feel truly work and are must-haves for a next-generation framework.
>>Heck, the results of such a question could wind up being your goal
>>statement entirely :)
>>
>>I would also make the point that Struts is the market leader for good
>>reason and so I would hope it isn't the fourth banana in the group.
>>Some people seem to believe that Struts is obsolete, or is rapidly
>>becoming so, is showing it's age, etc. I believe this is only the case,
>>if in fact it is, because it has been allowed to stagnate a bit in terms
>>of truly evolving. It has been on autopilot for way too long and other
>>frameworks have had a chance to pass it by. Be that as it may, the
>>point is that I believe for a new framework to be successful it should
>>take more cues from Struts on what TO do rather than what NOT to do.
>>Anything less is, IMO, foolishly ignoring the reputation and community
>>and success that Struts has enjoyed.
>>
>>Those are my initial thoughts. In any case, I offer my sincerest Good
>>Luck in the endeavor, I'll be interested to see how it goes.
>>
>>--
>>Frank W. Zammetti
>>Founder and Chief Software Architect
>>Omnytex Technologies
>>http://www.omnytex.com
>>AIM: fzammetti
>>Yahoo: fzammetti
>>MSN: fzammetti@hotmail.com
>>
>>Don Brown wrote:
>>
>>
>>>Consolidation is a relatively unknown concept in the crowded web
>>>framework space. While most frameworks are open source allowing
>>>cross-pollination, collaboration is still rare resulting in duplicated
>>>efforts and confusion for the end user. Struts Ti, a next-gen project
>>>in the Struts sandbox, tried to buck the trend by building on WebWork
>>>rather than wasting its time writing yet another Model2 framework.
>>>
>>>Taking this level of cooperation to the next level, developers from four
>>>popular web frameworks - Struts, Spring, WebWork, and Beehive, have
>>>gotten together to discuss the possibility of consolidating their
>>>efforts into a new project, termed Clarity. Clarity would be an
>>>action-based MVC framework that combines the commonality of the four
>>>aforementioned frameworks into one that can be built upon by all.
>>>
>>>These discussions have just began, and while no one has "officially"
>>>signed on, I thought I should bring it before the Struts community for
>>>feedback. There is still much to work out, but I want to keep the
>>>community involved from the beginning.
>>>
>>>I personally am excited about this project and think it will be
>>>beneficial to users and developers alike. The Struts Classic code base
>>>is showing its age, but speaking as a developer who maintains old Struts
>>>apps, few people have the time and budget to rewrite them from scratch
>>>with a more disparate framework like Shale or Wicket. I think Clarity
>>>would be a much easier migration for existing Struts applications and
>>>developers, yet support key standards like Portlets and JSF.
>>>
>>>Attached is two messages in a private email thread between Patrick
>>>Lightbody (WebWork), Keith Donald (Spring), Rich Feit (Beehive), and me,
>>>that started the Clarity discussion. We plan to have a public email
>>>list for Clarity discussion, but it hasn't been setup yet.
>>>
>>>What I'm looking for from the Struts community is if you think this is a
>>>good idea, and if you do, what we need to do to make it work.
>>>Personally, I don't expect Struts or even Struts Classic going away at
>>>all even if we agreed Clarity is migration path, so this isn't an
>>>either/or discussion.
>>>
>>>Again, this is _NOT_ a project announcement meant for the world, only
>>>the beginning of a discussion about the idea of consolidating a few web
>>>frameworks and how Struts fits in with this. Looking forward to the
>>>comments,
>>>
>>>Don
>>>
>>>=== Initial kickoff by Patrick Lightbody from WebWork ===
>>>Patrick Lightbody wrote:
>>> > (Warning: long email ahead. Don't worry, this isn't usually my style
>>> > and I'll stick to brief emails moving forward.)
>>> >
>>> > Hey guys -- this is the official "kickoff" of the project we've all
>>> > been talking about. Keith had a great code name for the project:
>>>Clarity.
>>> >
>>> > Before I get started, I just wanted to clarify the following people
>>> > involved and what their roles are:
>>> >
>>> > - Keith represents the Spring team, including the Spring MVC and
>>> > Spring WebFlow process. For now he will handle all the communication
>>> > between this project and the rest of the Spring folks.
>>> > - Jason is the primary technical representative from the WebWork team.
>>> > While I can add some info, I expect Jason will offer most of the
>>> > technical thoughts. Jason uses Spring and has a lot to offer here.
>>> > - Don Brown is a Struts committer and represents the Struts team (or
>>> > at least some of them). Don is the force behind Struts Ti and can
>>> > provide a lot of insight as user of WebWork and XWork, with both a
>>> > Struts and simplified "flavor" to it.
>>> > - Rich represents the Beehive team and also works on the Struts Ti
>>> > project. Rich will represent most of the Beehive input.
>>> > - Finally, I hope to, more than anything, act as a facilitator for
>>> > this whole project. Obviously I have a WebWork-slanted perspective, but
>>> > I believe that facilitating this process is more important than any set
>>> > of features or implementations choices.
>>> >
>>> > As I mentioned to you guys individually, I think the best way to move
>>> > forward is to take the following steps. I've taken a stab at the first
>>> > item as well.
>>> >
>>> > 1) Establish the rules: a small, agreed upon list of rules that we
>>> > promise to adhere to while working on this project. These will be
>>> > especially important in the early phases.
>>> >
>>> > 1) Complete a statement: we need to come up with a single paragraph
>>> > that sums up this effort. It should include the desire to work
>>> > together, the desire for clarity in the java web space, and the desire
>>> > to move beyond "petty" differences about implementation choices. In
>>> > short, this mission statement, when releases as a press release to the
>>> > entire community, should be powerful enough to get everyone excited
>>> > about it and know for sure that _this_ is the effort that will bring
>>> > web development productivity back to the Java camp.
>>> >
>>> > 2) Announce the project: we need to gather excitement around this as
>>> > soon as possible. Doing so will not only get us early feedback from the
>>> > community, it will most likely stave off a few more web frameworks from
>>> > being created (I found two more just today - eek!).
>>> >
>>> > 3) Set up a neutral place to host the project, including SVN, wiki, bug
>>> > tracker, etc. This place must be detached from Jakarta/Struts, Spring,
>>> > and OpenSymphony and must stay that way until we all feel comfortable
>>> > working together. That will likely happen about half way through
>>>step 4...
>>> >
>>> > 4) Now for the hard part: map out a technical implementation.
>>> >
>>> > 5) Release and re-establish Java as the place to build web
>>> > applications. I hope for this to happen within 8-12 months time,
>>> > starting today.
>>> >
>>> > So here are my ideal set of rules. Please adjust as you see fit:
>>> >
>>> > - Above all else, we recognize that consolidation is the overriding
>>> goal.
>>> > - We recognize that we'll all have to compromise on items we are
>>> > passionate about, but that the overall project success is more
>>>important.
>>> > - This project aims to unify WebWork, Struts, Spring MVC, Beehive, and
>>> > Spring WebFlow in to a single project that establishes clear leadership
>>> > in the web development space.
>>> > - All project leaders understand that once this project is releases,
>>> > future work their own projects should cease (other than supporting it,
>>> > minor releases, migration path to Clarity, etc).
>>> > - Technical disputes should be coordinated by those _least_ familiar
>>> > with the topic, and therefore least biased.
>>> > - When criticizing or proposing alternatives or otherwise "stopping
>>> > forward progress" - we promise to ask ourselves if this issue we're
>>> > about to raise is really "worth it".
>>> > - We recognize that not everyone works the way we do and we understand
>>> > that we may have to work hard to find common ground.
>>> >
>>> > So what's next? Let's nail down the rules and then move on to a mission
>>> > statement that we can announce. Remember: once we announce this,
>>> > there's no going back, so let's spend some time on the rules and the
>>> > mission statement. For now, please email back and forth any
>>> > edits/additions to the rules.
>>> >
>>> > This is really exciting! Sorry for the long email and the (likely very)
>>> > bureaucratic approach I'm taking with this -- I hope it adds some
>>>value.
>>> >
>>> > Patrick
>>>
>>>=== Keith Donald from Spring Web Flow/MVC ===
>>>
>>>Keith Donald wrote:
>>> > I think a good first step is to clearly state what we all expect to
>>>gain out
>>> > of working together, given the dynamics of this market, and what our
>>> > individual expectations are:
>>> >
>>> > Here's my take:
>>> > --------------
>>> > If you look at the open source web framework market, I see these camps:
>>> >
>>> > 1. Action-centric (Struts Classic, Struts Ti, Spring MVC, WW, SWF,
>>>Beehive)
>>> > 2. Component-centric (JSF-based <Struts Shale, JBoss Seam>, Tapestry,
>>> > Wicket, Echo)
>>> > 3. Ruby on Rails
>>> >
>>> > Options in camps #2 and #3 represent considerable more shock to adopt
>>>than
>>> > those in #1. This is for various reasons, but mainly because the
>>>majority
>>> > of the market (existing Struts users) can more naturally migrate to the
>>> > other action-centric frameworks. Spring MVC, for example, has been
>>> > positioned as a more extensible Struts and that strategy has proven
>>>fairly
>>> > effective. Spring Web Flow, is usable as a component from within both
>>> > Struts classic and Spring MVC, and that too has proven effective.
>>>Beehive
>>> > is built on Struts.
>>> >
>>> > So there is definite overlap (and some compliment, too) between Struts,
>>> > Spring MVC, WW, SWF, and Beehive, and I think it's fair to say we share
>>> > similar goals for tackling the same problems. Because of this, there
>>>is a
>>> > natural fit for consolidation/collaboration, motivated more now by two
>>> > external forces:
>>> >
>>> > 1. Camps #2 and #3 are threats. RoR is one, JBoss Seam is another.
>>> >
>>> > 2. The market is fragmented, and that creates user confusion. There
>>>is no
>>> > clear "next paradigm" <is JSF the base for that or not?>, and that
>>>creates
>>> > (encourages?) opportunity for new entrants with little invested thus
>>>far to
>>> > jump in and steal the show (look what Seam is trying to do, and the
>>>RoR hype
>>> > coming from high-profile independents in the Java community).
>>> >
>>> > --
>>> >
>>> > So the "clarity" project in my mind should be about providing a clear
>>>"next"
>>> > choice in the web-space for the Struts Classic, TI, WW, Beehive, and
>>>Spring
>>> > communities, with the premise being we'd be a lot stronger together
>>>than we
>>> > would competing with one another in essentially similar (but slightly
>>> > different) ways.
>>> >
>>> > From my perspective, I think it's important to market a full-stack
>>>product,
>>> > "clarity", which unites our respective brands/technologies; however,
>>>I feel
>>> > it's just as important that such a stack be built from a set of
>>> > best-of-breed components that lends itself to choice. For example, we
>>> > wouldn't want to just ignore JSF, it's not going away (and that is
>>>exactly
>>> > why Spring has made JSF integration a high priority, integrating SWF
>>>as a
>>> > more powerful JSF NavigationHandler).
>>> >
>>> > The ultimate goal, though, would be to win on the full-stack, the
>>>"clarity"
>>> > brand, appealing to a message of simplicity comparable to RoR but
>>>without
>>> > the shock.
>>> >
>>> > Interface21 would be willing to fund marketing and technical effort
>>>behind
>>> > this (including hosting infrastructure), hopefully with the support
>>>of BEA
>>> > as well.
>>> >
>>> > --
>>> >
>>> > From Spring's perspective there are a couple of expectations/issues I
>>>want
>>> > to get out there:
>>> >
>>> > - Spring in general has moved from being the gem of the technology
>>> > enthusiasts to more of a rock for the pragmatists (early majority).
>>>This is
>>> > more of the case for Spring's middle ware stack (IoC/TX/DAO/etc), but
>>>Spring
>>> > MVC also applies to some degree as it is shipped with the core
>>>framework.
>>> > Among other things, this means Interface21 and BEA are now in the
>>>business
>>> > of providing Spring support/training/certification, and that entails
>>> > contractual obligations for supporting existing versions of Spring.
>>>So work
>>> > on any part of the framework just can't stop on a dime: we must
>>>continue to
>>> > support our customers. Backwards compatibility, as well as the
>>>ability to
>>> > run on existing infrastructure <JDK 1.3 or >), is very important to
>>>us for
>>> > this reason.
>>> >
>>> > With that said, however, we do expect more support work around Spring's
>>> > middle ware stack, as it is more widely used than Spring MVC. So we
>>>do have
>>> > more flexibility for change with Spring MVC, but we just can't stop
>>> > supporting it. Likewise, we'd want a "clarity" migration from Spring
>>>MVC to
>>> > be as easy as possible.
>>> >
>>> > I think ease of adoption is important to all of us, else our own
>>>communities
>>> > may turn on us.
>>> >
>>> > - Spring Web Flow represents a major investment for us in the last year.
>>> > We've put much more resources into SWF than we have MVC, as MVC has
>>>always
>>> > been a foundation to build on while SWF is a full-featured page flow
>>> > product. SWF is also at a different place in the market than MVC: as
>>>a new
>>> > product positioned as a breakthrough technology, it is the gem of the
>>> > enthusiast at this point. We expect when it reaches 1.0 it will become
>>> > widely adopted quickly, as it has considerable momentum now, and is well
>>> > positioned.
>>> >
>>> > Given that, I see opportunity with Clarity to capitalize on synergy
>>>between
>>> > SWF and Beehive PF and also leverage the momentum of SWF's
>>>approaching 1.0
>>> > release. I do have concerns of dilution: we wouldn't want to dilute the
>>> > effort/branding we've put into SWF, and risk losing the momentum we
>>>have now
>>> > (or worse, giving it away to say JBoss Seam, who is trying to play
>>>catchup
>>> > with both of us).
>>> >
>>> > What I'm saying is SWF is going to be successful on its own, as a new
>>> > product addressing an untapped niche, so we want to make sure we take
>>> > advantage of that with Clarity without dilution... and do so quickly,
>>>before
>>> > other competitors have a chance to stake a claim by copying it and
>>>making
>>> > the clone a part of their "full stack".
>>> >
>>> > --
>>> >
>>> > I hope this provides some insight into where Spring is coming from
>>>and our
>>> > interest with Clarity. I feel this is unique opportunity to come
>>>together
>>> > and leverage the best in each of our respective products, and unite our
>>> > communities under a common brand whose development is sustained not
>>>only by
>>> > open source developers but commercial companies such as Interface21
>>>and BEA
>>> > as well.
>>> >
>>> > Once we have it out in the open what we all hope to gain, I think a good
>>> > next step is to start flushing out from a technical perspective what
>>>this
>>> > thing would look like--in the ideal, and keeping in mind migration
>>>from our
>>> > existing products, and the need for components at each key part in the
>>> > stack. Once the technical architecture is understood, then I think it's
>>> > natural to start focusing on marketing/branding.
>>> >
>>> > Keith
>>> >
>>> > -----Original Message-----
>>> > From: Patrick Lightbody [mailto:plightbo@gmail.com]
>>> > Sent: Thursday, October 06, 2005 11:20 AM
>>> > To: Rich Feit
>>> > Cc: Keith Donald; Don Brown; Jason Carreira
>>> > Subject: Re: Project Clarity Kickoff
>>> >
>>> > Rich,
>>> > Yes, the project of course would be open source and likely Apache 2.0
>>> > License.
>>> >
>>> > I agree: Our mission statement must give a high level detail of the
>>> > project as well, clarifying the space.
>>> >
>>> > I also think the wikis/infrastructure should be open.
>>> >
>>> > As for technical details (step #4), when we get there we will
>>> > definitely focus on framework features and characterization. I just
>>> > don't want to dive in to these things yet - as some topics can and
>>> > will be very contentious. That's why I'm avoiding a reply to Jason's
>>> > email :)
>>> >
>>> > You're right -- that rule about "stopping the other projects" is
>>> > simply there to make sure that we all understand that competing
>>> > efforts would be ramped down. I think we all know that, so it may not
>>> > even be worth stating.
>>> >
>>> > Patrick
>>> >
>>> > On Oct 6, 2005, at 12:21 AM, Rich Feit wrote:
>>> >
>>> >
>>> >>Patrick,
>>> >>
>>> >>This *is* really exciting -- if Clarity comes about, it'll cut through
>>> >>the confusion that's starting to dominate this space.
>>> >>
>>> >>I think you're setting this up really well. I have a few specific
>>> >>comments, but my first is this: before I could commit Beehive to the
>>> >>project, I have to be able to share it with the Beehive community,
>>> >>even
>>> >>at this early stage. Some kind of message that says a bunch of key
>>> >>projects want to consolidate to eliminate overlap, and that this would
>>> >>supplant a chunk of Beehive. Committers vote, possibly tell me to
>>> >>go to
>>> >>hell. I assume this isn't a problem, but I want to make sure it's out
>>> >>there. (Don, I guess you're in the same boat...?)
>>> >>
>>> >>Some specifics inline...
>>> >>
>>> >>Patrick Lightbody wrote:
>>> >>
>>> >>
>>> >>
>>> >>>(Warning: long email ahead. Don't worry, this isn't usually my style
>>> >>>and I'll stick to brief emails moving forward.)
>>> >>>
>>> >>>Hey guys -- this is the official "kickoff" of the project we've all
>>> >>>been talking about. Keith had a great code name for the project:
>>> >>>Clarity.
>>> >>>
>>> >>>Before I get started, I just wanted to clarify the following people
>>> >>>involved and what their roles are:
>>> >>>
>>> >>> - Keith represents the Spring team, including the Spring MVC and
>>> >>>Spring WebFlow process. For now he will handle all the communication
>>> >>>between this project and the rest of the Spring folks.
>>> >>> - Jason is the primary technical representative from the WebWork
>>> >>>team. While I can add some info, I expect Jason will offer most of
>>> >>>the technical thoughts. Jason uses Spring and has a lot to offer
>>> >>>here.
>>> >>> - Don Brown is a Struts committer and represents the Struts team
>>> >>>(or
>>> >>>at least some of them). Don is the force behind Struts Ti and can
>>> >>>provide a lot of insight as user of WebWork and XWork, with both a
>>> >>>Struts and simplified "flavor" to it.
>>> >>> - Rich represents the Beehive team and also works on the Struts Ti
>>> >>>project. Rich will represent most of the Beehive input.
>>> >>> - Finally, I hope to, more than anything, act as a facilitator for
>>> >>>this whole project. Obviously I have a WebWork-slanted perspective,
>>> >>>but I believe that facilitating this process is more important than
>>> >>>any set of features or implementations choices.
>>> >>>
>>> >>>As I mentioned to you guys individually, I think the best way to move
>>> >>>forward is to take the following steps. I've taken a stab at the
>>> >>>first item as well.
>>> >>>
>>> >>>
>>> >>
>>> >> 0) Agree on the software license. Without the right license
>>> >>(ASF),
>>> >>I'm guessing many of us wouldn't be able to participate.
>>> >>
>>> >>Also, a basic question. Is this an open source project?
>>> >>
>>> >>
>>> >>
>>> >>>1) Establish the rules: a small, agreed upon list of rules that we
>>> >>>promise to adhere to while working on this project. These will be
>>> >>>especially important in the early phases.
>>> >>>
>>> >>>1) Complete a statement: we need to come up with a single paragraph
>>> >>>that sums up this effort. It should include the desire to work
>>> >>>together, the desire for clarity in the java web space, and the
>>> >>>desire to move beyond "petty" differences about implementation
>>> >>>choices. In short, this mission statement, when releases as a press
>>> >>>release to the entire community, should be powerful enough to get
>>> >>>everyone excited about it and know for sure that _this_ is the effort
>>> >>>that will bring web development productivity back to the Java camp.
>>> >>>
>>> >>>
>>> >>
>>> >>Totally. The only thing I'd add here (maybe obvious) is that this
>>> >>should go beyond the desire to work together and bring clarity to the
>>> >>space -- some high-level characterization of what the framework itself
>>> >>is about.
>>> >>
>>> >>
>>> >>
>>> >>>2) Announce the project: we need to gather excitement around this as
>>> >>>soon as possible. Doing so will not only get us early feedback from
>>> >>>the community, it will most likely stave off a few more web
>>> >>>frameworks from being created (I found two more just today - eek!).
>>> >>>
>>> >>>3) Set up a neutral place to host the project, including SVN, wiki,
>>> >>>bug tracker, etc. This place must be detached from Jakarta/Struts,
>>> >>>Spring, and OpenSymphony and must stay that way until we all feel
>>> >>>comfortable working together. That will likely happen about half way
>>> >>>through step 4...
>>> >>>
>>> >>>
>>> >>
>>> >>It would be as open as the wikis, mailing lists, repositories, etc. of
>>> >>the rest of the projects, right?
>>> >>
>>> >> [additional item -- maybe falls under #4] Agree on general features
>>> >>and characteristics of the framework. Some examples (note: I'm not
>>> >>assuming everyone would agree to these particular ones :) ):
>>> >> - support entities that are flow controllers as first class
>>> >>citizens
>>> >> - support the association of per-user state with a flow controller
>>> >> - allow Java 5 annotations as a way to configure controllers
>>> >> - provide a fast no-redeploy iterative dev experience
>>> >>
>>> >> [additional item -- maybe falls under #4] Mock up some files/
>>> >>artifacts
>>> >>as the user would see/write them. Like what Don did early on in Ti
>>> >>(http://wiki.apache.org/struts/StrutsTi/ControllerMock ).
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>>4) Now for the hard part: map out a technical implementation.
>>> >>>
>>> >>>5) Release and re-establish Java as the place to build web
>>> >>>applications. I hope for this to happen within 8-12 months time,
>>> >>>starting today.
>>> >>>
>>> >>>So here are my ideal set of rules. Please adjust as you see fit:
>>> >>>
>>> >>> - Above all else, we recognize that consolidation is the overriding
>>> >>>goal.
>>> >>> - We recognize that we'll all have to compromise on items we are
>>> >>>passionate about, but that the overall project success is more
>>> >>>important.
>>> >>> - This project aims to unify WebWork, Struts, Spring MVC, Beehive,
>>> >>>and Spring WebFlow in to a single project that establishes clear
>>> >>>leadership in the web development space.
>>> >>> - All project leaders understand that once this project is
>>> >>>releases,
>>> >>>future work their own projects should cease (other than supporting
>>> >>>it, minor releases, migration path to Clarity, etc).
>>> >>> - Technical disputes should be coordinated by those _least_
>>> >>>familiar
>>> >>>with the topic, and therefore least biased.
>>> >>> - When criticizing or proposing alternatives or otherwise "stopping
>>> >>>forward progress" - we promise to ask ourselves if this issue we're
>>> >>>about to raise is really "worth it".
>>> >>> - We recognize that not everyone works the way we do and we
>>> >>>understand that we may have to work hard to find common ground.
>>> >>>
>>> >>>
>>> >>
>>> >> The rules... I agree, for us to succeed, we need these. We'll all
>>> >>have to take as a prime goal compromise/progress over dogma. My main
>>> >>comment is about consolidation and ceasing development on the ancestor
>>> >>projects. Beehive has components that I assume are far outside the
>>> >>mission of Clarity (e.g., JSR 181 Web Services Metadata
>>> >>implementation). Just want to make sure we're not trumpeting the
>>> >>death
>>> >>of entire frameworks that don't overlap. Relatedly, I feel that the
>>> >>cease-development clause should go something like this:
>>> >> "... will cease developing features that overlap with features
>>> >>in Clarity."
>>> >> It's clearly not in the interest of any project to keep plugging
>>> >>along with a redundant framework (c'mon, how can you compete with
>>> >>Clarity? :) ), but I imagine that many features will fall outside the
>>> >>scope of what's done here.
>>> >>
>>> >>A final question: would people agree that we should start core/focused
>>> >>(e.g., controller tier, view agnostic, not trying to define an entire
>>> >>stack)? Seems like this is something that would help us move forward
>>> >>more quickly, and would prevent us from trying to make too many leaf
>>> >>nodes part of the trunk.
>>> >>
>>> >>
>>> >>
>>> >>>So what's next? Let's nail down the rules and then move on to a
>>> >>>mission statement that we can announce. Remember: once we announce
>>> >>>this, there's no going back, so let's spend some time on the rules
>>> >>>and the mission statement. For now, please email back and forth any
>>> >>>edits/additions to the rules.
>>> >>>
>>> >>>This is really exciting! Sorry for the long email and the (likely
>>> >>>very) bureaucratic approach I'm taking with this -- I hope it adds
>>> >>>some value.
>>> >>>
>>> >>>Patrick
>>> >>>
>>> >>>
>>> >>
>>> >>Exciting stuff!
>>> >>
>>> >>Rich
>>> >>
>>> >
>>> >
>>> >
>>>
>>>
>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>For additional commands, e-mail: dev-help@struts.apache.org
>>>
>>>
>>>
>>>
>>>
>>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>>
>>
>
>
>--
>"You can lead a horse to water but you cannot make it float on its back."
>~Dakota Jack~
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>For additional commands, e-mail: dev-help@struts.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Web Framework Consolidation
Posted by Dakota Jack <da...@gmail.com>.
Bolting JSF onto Struts makes no sense. They are simply incompatible.
If you want to do something with the merits of both, you still have
to choose which way you want to go. You cannot go both ways, unless
you are doing it just to fish people in.
On 10/10/05, Frank W. Zammetti <fz...@omnytex.com> wrote:
> Just a few opinions from the peanut gallery...
>
> The era of the "classic" webapp is dead. Any new framework that doesn't
> make it easy (well, EASIER anyway) to develop robust RIAs is dead on
> arrival as far as I am concerned.
>
> Further, I do not believe that the action-centric and component-centric
> models need be exclusive of each other and in fact I believe that is the
> natural evolution of things. I don't think this necessarily implies an
> approach like bolting JSF onto Struts for example, but then again maybe
> that is the most natural path. The real point though is the merging of
> the two approaches into *something*, whatever that something winds up being.
>
> So, if Clarity is going to take into consideration the building of RIAs
> at its core, than I for one will be interested in how it evolves. IF
> that isn't a central theme though, then it's DOA from my perspective.
>
> All of the frameworks involved do many things right, so it would seem
> logical to me that as long as you choose the things that work to merge,
> the end result should be pretty good. I would start by getting input
> from the community on what aspects of the contributing frameworks they
> feel truly work and are must-haves for a next-generation framework.
> Heck, the results of such a question could wind up being your goal
> statement entirely :)
>
> I would also make the point that Struts is the market leader for good
> reason and so I would hope it isn't the fourth banana in the group.
> Some people seem to believe that Struts is obsolete, or is rapidly
> becoming so, is showing it's age, etc. I believe this is only the case,
> if in fact it is, because it has been allowed to stagnate a bit in terms
> of truly evolving. It has been on autopilot for way too long and other
> frameworks have had a chance to pass it by. Be that as it may, the
> point is that I believe for a new framework to be successful it should
> take more cues from Struts on what TO do rather than what NOT to do.
> Anything less is, IMO, foolishly ignoring the reputation and community
> and success that Struts has enjoyed.
>
> Those are my initial thoughts. In any case, I offer my sincerest Good
> Luck in the endeavor, I'll be interested to see how it goes.
>
> --
> Frank W. Zammetti
> Founder and Chief Software Architect
> Omnytex Technologies
> http://www.omnytex.com
> AIM: fzammetti
> Yahoo: fzammetti
> MSN: fzammetti@hotmail.com
>
> Don Brown wrote:
> > Consolidation is a relatively unknown concept in the crowded web
> > framework space. While most frameworks are open source allowing
> > cross-pollination, collaboration is still rare resulting in duplicated
> > efforts and confusion for the end user. Struts Ti, a next-gen project
> > in the Struts sandbox, tried to buck the trend by building on WebWork
> > rather than wasting its time writing yet another Model2 framework.
> >
> > Taking this level of cooperation to the next level, developers from four
> > popular web frameworks - Struts, Spring, WebWork, and Beehive, have
> > gotten together to discuss the possibility of consolidating their
> > efforts into a new project, termed Clarity. Clarity would be an
> > action-based MVC framework that combines the commonality of the four
> > aforementioned frameworks into one that can be built upon by all.
> >
> > These discussions have just began, and while no one has "officially"
> > signed on, I thought I should bring it before the Struts community for
> > feedback. There is still much to work out, but I want to keep the
> > community involved from the beginning.
> >
> > I personally am excited about this project and think it will be
> > beneficial to users and developers alike. The Struts Classic code base
> > is showing its age, but speaking as a developer who maintains old Struts
> > apps, few people have the time and budget to rewrite them from scratch
> > with a more disparate framework like Shale or Wicket. I think Clarity
> > would be a much easier migration for existing Struts applications and
> > developers, yet support key standards like Portlets and JSF.
> >
> > Attached is two messages in a private email thread between Patrick
> > Lightbody (WebWork), Keith Donald (Spring), Rich Feit (Beehive), and me,
> > that started the Clarity discussion. We plan to have a public email
> > list for Clarity discussion, but it hasn't been setup yet.
> >
> > What I'm looking for from the Struts community is if you think this is a
> > good idea, and if you do, what we need to do to make it work.
> > Personally, I don't expect Struts or even Struts Classic going away at
> > all even if we agreed Clarity is migration path, so this isn't an
> > either/or discussion.
> >
> > Again, this is _NOT_ a project announcement meant for the world, only
> > the beginning of a discussion about the idea of consolidating a few web
> > frameworks and how Struts fits in with this. Looking forward to the
> > comments,
> >
> > Don
> >
> > === Initial kickoff by Patrick Lightbody from WebWork ===
> > Patrick Lightbody wrote:
> > > (Warning: long email ahead. Don't worry, this isn't usually my style
> > > and I'll stick to brief emails moving forward.)
> > >
> > > Hey guys -- this is the official "kickoff" of the project we've all
> > > been talking about. Keith had a great code name for the project:
> > Clarity.
> > >
> > > Before I get started, I just wanted to clarify the following people
> > > involved and what their roles are:
> > >
> > > - Keith represents the Spring team, including the Spring MVC and
> > > Spring WebFlow process. For now he will handle all the communication
> > > between this project and the rest of the Spring folks.
> > > - Jason is the primary technical representative from the WebWork team.
> > > While I can add some info, I expect Jason will offer most of the
> > > technical thoughts. Jason uses Spring and has a lot to offer here.
> > > - Don Brown is a Struts committer and represents the Struts team (or
> > > at least some of them). Don is the force behind Struts Ti and can
> > > provide a lot of insight as user of WebWork and XWork, with both a
> > > Struts and simplified "flavor" to it.
> > > - Rich represents the Beehive team and also works on the Struts Ti
> > > project. Rich will represent most of the Beehive input.
> > > - Finally, I hope to, more than anything, act as a facilitator for
> > > this whole project. Obviously I have a WebWork-slanted perspective, but
> > > I believe that facilitating this process is more important than any set
> > > of features or implementations choices.
> > >
> > > As I mentioned to you guys individually, I think the best way to move
> > > forward is to take the following steps. I've taken a stab at the first
> > > item as well.
> > >
> > > 1) Establish the rules: a small, agreed upon list of rules that we
> > > promise to adhere to while working on this project. These will be
> > > especially important in the early phases.
> > >
> > > 1) Complete a statement: we need to come up with a single paragraph
> > > that sums up this effort. It should include the desire to work
> > > together, the desire for clarity in the java web space, and the desire
> > > to move beyond "petty" differences about implementation choices. In
> > > short, this mission statement, when releases as a press release to the
> > > entire community, should be powerful enough to get everyone excited
> > > about it and know for sure that _this_ is the effort that will bring
> > > web development productivity back to the Java camp.
> > >
> > > 2) Announce the project: we need to gather excitement around this as
> > > soon as possible. Doing so will not only get us early feedback from the
> > > community, it will most likely stave off a few more web frameworks from
> > > being created (I found two more just today - eek!).
> > >
> > > 3) Set up a neutral place to host the project, including SVN, wiki, bug
> > > tracker, etc. This place must be detached from Jakarta/Struts, Spring,
> > > and OpenSymphony and must stay that way until we all feel comfortable
> > > working together. That will likely happen about half way through
> > step 4...
> > >
> > > 4) Now for the hard part: map out a technical implementation.
> > >
> > > 5) Release and re-establish Java as the place to build web
> > > applications. I hope for this to happen within 8-12 months time,
> > > starting today.
> > >
> > > So here are my ideal set of rules. Please adjust as you see fit:
> > >
> > > - Above all else, we recognize that consolidation is the overriding
> > goal.
> > > - We recognize that we'll all have to compromise on items we are
> > > passionate about, but that the overall project success is more
> > important.
> > > - This project aims to unify WebWork, Struts, Spring MVC, Beehive, and
> > > Spring WebFlow in to a single project that establishes clear leadership
> > > in the web development space.
> > > - All project leaders understand that once this project is releases,
> > > future work their own projects should cease (other than supporting it,
> > > minor releases, migration path to Clarity, etc).
> > > - Technical disputes should be coordinated by those _least_ familiar
> > > with the topic, and therefore least biased.
> > > - When criticizing or proposing alternatives or otherwise "stopping
> > > forward progress" - we promise to ask ourselves if this issue we're
> > > about to raise is really "worth it".
> > > - We recognize that not everyone works the way we do and we understand
> > > that we may have to work hard to find common ground.
> > >
> > > So what's next? Let's nail down the rules and then move on to a mission
> > > statement that we can announce. Remember: once we announce this,
> > > there's no going back, so let's spend some time on the rules and the
> > > mission statement. For now, please email back and forth any
> > > edits/additions to the rules.
> > >
> > > This is really exciting! Sorry for the long email and the (likely very)
> > > bureaucratic approach I'm taking with this -- I hope it adds some
> > value.
> > >
> > > Patrick
> >
> > === Keith Donald from Spring Web Flow/MVC ===
> >
> > Keith Donald wrote:
> > > I think a good first step is to clearly state what we all expect to
> > gain out
> > > of working together, given the dynamics of this market, and what our
> > > individual expectations are:
> > >
> > > Here's my take:
> > > --------------
> > > If you look at the open source web framework market, I see these camps:
> > >
> > > 1. Action-centric (Struts Classic, Struts Ti, Spring MVC, WW, SWF,
> > Beehive)
> > > 2. Component-centric (JSF-based <Struts Shale, JBoss Seam>, Tapestry,
> > > Wicket, Echo)
> > > 3. Ruby on Rails
> > >
> > > Options in camps #2 and #3 represent considerable more shock to adopt
> > than
> > > those in #1. This is for various reasons, but mainly because the
> > majority
> > > of the market (existing Struts users) can more naturally migrate to the
> > > other action-centric frameworks. Spring MVC, for example, has been
> > > positioned as a more extensible Struts and that strategy has proven
> > fairly
> > > effective. Spring Web Flow, is usable as a component from within both
> > > Struts classic and Spring MVC, and that too has proven effective.
> > Beehive
> > > is built on Struts.
> > >
> > > So there is definite overlap (and some compliment, too) between Struts,
> > > Spring MVC, WW, SWF, and Beehive, and I think it's fair to say we share
> > > similar goals for tackling the same problems. Because of this, there
> > is a
> > > natural fit for consolidation/collaboration, motivated more now by two
> > > external forces:
> > >
> > > 1. Camps #2 and #3 are threats. RoR is one, JBoss Seam is another.
> > >
> > > 2. The market is fragmented, and that creates user confusion. There
> > is no
> > > clear "next paradigm" <is JSF the base for that or not?>, and that
> > creates
> > > (encourages?) opportunity for new entrants with little invested thus
> > far to
> > > jump in and steal the show (look what Seam is trying to do, and the
> > RoR hype
> > > coming from high-profile independents in the Java community).
> > >
> > > --
> > >
> > > So the "clarity" project in my mind should be about providing a clear
> > "next"
> > > choice in the web-space for the Struts Classic, TI, WW, Beehive, and
> > Spring
> > > communities, with the premise being we'd be a lot stronger together
> > than we
> > > would competing with one another in essentially similar (but slightly
> > > different) ways.
> > >
> > > From my perspective, I think it's important to market a full-stack
> > product,
> > > "clarity", which unites our respective brands/technologies; however,
> > I feel
> > > it's just as important that such a stack be built from a set of
> > > best-of-breed components that lends itself to choice. For example, we
> > > wouldn't want to just ignore JSF, it's not going away (and that is
> > exactly
> > > why Spring has made JSF integration a high priority, integrating SWF
> > as a
> > > more powerful JSF NavigationHandler).
> > >
> > > The ultimate goal, though, would be to win on the full-stack, the
> > "clarity"
> > > brand, appealing to a message of simplicity comparable to RoR but
> > without
> > > the shock.
> > >
> > > Interface21 would be willing to fund marketing and technical effort
> > behind
> > > this (including hosting infrastructure), hopefully with the support
> > of BEA
> > > as well.
> > >
> > > --
> > >
> > > From Spring's perspective there are a couple of expectations/issues I
> > want
> > > to get out there:
> > >
> > > - Spring in general has moved from being the gem of the technology
> > > enthusiasts to more of a rock for the pragmatists (early majority).
> > This is
> > > more of the case for Spring's middle ware stack (IoC/TX/DAO/etc), but
> > Spring
> > > MVC also applies to some degree as it is shipped with the core
> > framework.
> > > Among other things, this means Interface21 and BEA are now in the
> > business
> > > of providing Spring support/training/certification, and that entails
> > > contractual obligations for supporting existing versions of Spring.
> > So work
> > > on any part of the framework just can't stop on a dime: we must
> > continue to
> > > support our customers. Backwards compatibility, as well as the
> > ability to
> > > run on existing infrastructure <JDK 1.3 or >), is very important to
> > us for
> > > this reason.
> > >
> > > With that said, however, we do expect more support work around Spring's
> > > middle ware stack, as it is more widely used than Spring MVC. So we
> > do have
> > > more flexibility for change with Spring MVC, but we just can't stop
> > > supporting it. Likewise, we'd want a "clarity" migration from Spring
> > MVC to
> > > be as easy as possible.
> > >
> > > I think ease of adoption is important to all of us, else our own
> > communities
> > > may turn on us.
> > >
> > > - Spring Web Flow represents a major investment for us in the last year.
> > > We've put much more resources into SWF than we have MVC, as MVC has
> > always
> > > been a foundation to build on while SWF is a full-featured page flow
> > > product. SWF is also at a different place in the market than MVC: as
> > a new
> > > product positioned as a breakthrough technology, it is the gem of the
> > > enthusiast at this point. We expect when it reaches 1.0 it will become
> > > widely adopted quickly, as it has considerable momentum now, and is well
> > > positioned.
> > >
> > > Given that, I see opportunity with Clarity to capitalize on synergy
> > between
> > > SWF and Beehive PF and also leverage the momentum of SWF's
> > approaching 1.0
> > > release. I do have concerns of dilution: we wouldn't want to dilute the
> > > effort/branding we've put into SWF, and risk losing the momentum we
> > have now
> > > (or worse, giving it away to say JBoss Seam, who is trying to play
> > catchup
> > > with both of us).
> > >
> > > What I'm saying is SWF is going to be successful on its own, as a new
> > > product addressing an untapped niche, so we want to make sure we take
> > > advantage of that with Clarity without dilution... and do so quickly,
> > before
> > > other competitors have a chance to stake a claim by copying it and
> > making
> > > the clone a part of their "full stack".
> > >
> > > --
> > >
> > > I hope this provides some insight into where Spring is coming from
> > and our
> > > interest with Clarity. I feel this is unique opportunity to come
> > together
> > > and leverage the best in each of our respective products, and unite our
> > > communities under a common brand whose development is sustained not
> > only by
> > > open source developers but commercial companies such as Interface21
> > and BEA
> > > as well.
> > >
> > > Once we have it out in the open what we all hope to gain, I think a good
> > > next step is to start flushing out from a technical perspective what
> > this
> > > thing would look like--in the ideal, and keeping in mind migration
> > from our
> > > existing products, and the need for components at each key part in the
> > > stack. Once the technical architecture is understood, then I think it's
> > > natural to start focusing on marketing/branding.
> > >
> > > Keith
> > >
> > > -----Original Message-----
> > > From: Patrick Lightbody [mailto:plightbo@gmail.com]
> > > Sent: Thursday, October 06, 2005 11:20 AM
> > > To: Rich Feit
> > > Cc: Keith Donald; Don Brown; Jason Carreira
> > > Subject: Re: Project Clarity Kickoff
> > >
> > > Rich,
> > > Yes, the project of course would be open source and likely Apache 2.0
> > > License.
> > >
> > > I agree: Our mission statement must give a high level detail of the
> > > project as well, clarifying the space.
> > >
> > > I also think the wikis/infrastructure should be open.
> > >
> > > As for technical details (step #4), when we get there we will
> > > definitely focus on framework features and characterization. I just
> > > don't want to dive in to these things yet - as some topics can and
> > > will be very contentious. That's why I'm avoiding a reply to Jason's
> > > email :)
> > >
> > > You're right -- that rule about "stopping the other projects" is
> > > simply there to make sure that we all understand that competing
> > > efforts would be ramped down. I think we all know that, so it may not
> > > even be worth stating.
> > >
> > > Patrick
> > >
> > > On Oct 6, 2005, at 12:21 AM, Rich Feit wrote:
> > >
> > >
> > >>Patrick,
> > >>
> > >>This *is* really exciting -- if Clarity comes about, it'll cut through
> > >>the confusion that's starting to dominate this space.
> > >>
> > >>I think you're setting this up really well. I have a few specific
> > >>comments, but my first is this: before I could commit Beehive to the
> > >>project, I have to be able to share it with the Beehive community,
> > >>even
> > >>at this early stage. Some kind of message that says a bunch of key
> > >>projects want to consolidate to eliminate overlap, and that this would
> > >>supplant a chunk of Beehive. Committers vote, possibly tell me to
> > >>go to
> > >>hell. I assume this isn't a problem, but I want to make sure it's out
> > >>there. (Don, I guess you're in the same boat...?)
> > >>
> > >>Some specifics inline...
> > >>
> > >>Patrick Lightbody wrote:
> > >>
> > >>
> > >>
> > >>>(Warning: long email ahead. Don't worry, this isn't usually my style
> > >>>and I'll stick to brief emails moving forward.)
> > >>>
> > >>>Hey guys -- this is the official "kickoff" of the project we've all
> > >>>been talking about. Keith had a great code name for the project:
> > >>>Clarity.
> > >>>
> > >>>Before I get started, I just wanted to clarify the following people
> > >>>involved and what their roles are:
> > >>>
> > >>> - Keith represents the Spring team, including the Spring MVC and
> > >>>Spring WebFlow process. For now he will handle all the communication
> > >>>between this project and the rest of the Spring folks.
> > >>> - Jason is the primary technical representative from the WebWork
> > >>>team. While I can add some info, I expect Jason will offer most of
> > >>>the technical thoughts. Jason uses Spring and has a lot to offer
> > >>>here.
> > >>> - Don Brown is a Struts committer and represents the Struts team
> > >>>(or
> > >>>at least some of them). Don is the force behind Struts Ti and can
> > >>>provide a lot of insight as user of WebWork and XWork, with both a
> > >>>Struts and simplified "flavor" to it.
> > >>> - Rich represents the Beehive team and also works on the Struts Ti
> > >>>project. Rich will represent most of the Beehive input.
> > >>> - Finally, I hope to, more than anything, act as a facilitator for
> > >>>this whole project. Obviously I have a WebWork-slanted perspective,
> > >>>but I believe that facilitating this process is more important than
> > >>>any set of features or implementations choices.
> > >>>
> > >>>As I mentioned to you guys individually, I think the best way to move
> > >>>forward is to take the following steps. I've taken a stab at the
> > >>>first item as well.
> > >>>
> > >>>
> > >>
> > >> 0) Agree on the software license. Without the right license
> > >>(ASF),
> > >>I'm guessing many of us wouldn't be able to participate.
> > >>
> > >>Also, a basic question. Is this an open source project?
> > >>
> > >>
> > >>
> > >>>1) Establish the rules: a small, agreed upon list of rules that we
> > >>>promise to adhere to while working on this project. These will be
> > >>>especially important in the early phases.
> > >>>
> > >>>1) Complete a statement: we need to come up with a single paragraph
> > >>>that sums up this effort. It should include the desire to work
> > >>>together, the desire for clarity in the java web space, and the
> > >>>desire to move beyond "petty" differences about implementation
> > >>>choices. In short, this mission statement, when releases as a press
> > >>>release to the entire community, should be powerful enough to get
> > >>>everyone excited about it and know for sure that _this_ is the effort
> > >>>that will bring web development productivity back to the Java camp.
> > >>>
> > >>>
> > >>
> > >>Totally. The only thing I'd add here (maybe obvious) is that this
> > >>should go beyond the desire to work together and bring clarity to the
> > >>space -- some high-level characterization of what the framework itself
> > >>is about.
> > >>
> > >>
> > >>
> > >>>2) Announce the project: we need to gather excitement around this as
> > >>>soon as possible. Doing so will not only get us early feedback from
> > >>>the community, it will most likely stave off a few more web
> > >>>frameworks from being created (I found two more just today - eek!).
> > >>>
> > >>>3) Set up a neutral place to host the project, including SVN, wiki,
> > >>>bug tracker, etc. This place must be detached from Jakarta/Struts,
> > >>>Spring, and OpenSymphony and must stay that way until we all feel
> > >>>comfortable working together. That will likely happen about half way
> > >>>through step 4...
> > >>>
> > >>>
> > >>
> > >>It would be as open as the wikis, mailing lists, repositories, etc. of
> > >>the rest of the projects, right?
> > >>
> > >> [additional item -- maybe falls under #4] Agree on general features
> > >>and characteristics of the framework. Some examples (note: I'm not
> > >>assuming everyone would agree to these particular ones :) ):
> > >> - support entities that are flow controllers as first class
> > >>citizens
> > >> - support the association of per-user state with a flow controller
> > >> - allow Java 5 annotations as a way to configure controllers
> > >> - provide a fast no-redeploy iterative dev experience
> > >>
> > >> [additional item -- maybe falls under #4] Mock up some files/
> > >>artifacts
> > >>as the user would see/write them. Like what Don did early on in Ti
> > >>(http://wiki.apache.org/struts/StrutsTi/ControllerMock ).
> > >>
> > >>
> > >>
> > >>
> > >>>4) Now for the hard part: map out a technical implementation.
> > >>>
> > >>>5) Release and re-establish Java as the place to build web
> > >>>applications. I hope for this to happen within 8-12 months time,
> > >>>starting today.
> > >>>
> > >>>So here are my ideal set of rules. Please adjust as you see fit:
> > >>>
> > >>> - Above all else, we recognize that consolidation is the overriding
> > >>>goal.
> > >>> - We recognize that we'll all have to compromise on items we are
> > >>>passionate about, but that the overall project success is more
> > >>>important.
> > >>> - This project aims to unify WebWork, Struts, Spring MVC, Beehive,
> > >>>and Spring WebFlow in to a single project that establishes clear
> > >>>leadership in the web development space.
> > >>> - All project leaders understand that once this project is
> > >>>releases,
> > >>>future work their own projects should cease (other than supporting
> > >>>it, minor releases, migration path to Clarity, etc).
> > >>> - Technical disputes should be coordinated by those _least_
> > >>>familiar
> > >>>with the topic, and therefore least biased.
> > >>> - When criticizing or proposing alternatives or otherwise "stopping
> > >>>forward progress" - we promise to ask ourselves if this issue we're
> > >>>about to raise is really "worth it".
> > >>> - We recognize that not everyone works the way we do and we
> > >>>understand that we may have to work hard to find common ground.
> > >>>
> > >>>
> > >>
> > >> The rules... I agree, for us to succeed, we need these. We'll all
> > >>have to take as a prime goal compromise/progress over dogma. My main
> > >>comment is about consolidation and ceasing development on the ancestor
> > >>projects. Beehive has components that I assume are far outside the
> > >>mission of Clarity (e.g., JSR 181 Web Services Metadata
> > >>implementation). Just want to make sure we're not trumpeting the
> > >>death
> > >>of entire frameworks that don't overlap. Relatedly, I feel that the
> > >>cease-development clause should go something like this:
> > >> "... will cease developing features that overlap with features
> > >>in Clarity."
> > >> It's clearly not in the interest of any project to keep plugging
> > >>along with a redundant framework (c'mon, how can you compete with
> > >>Clarity? :) ), but I imagine that many features will fall outside the
> > >>scope of what's done here.
> > >>
> > >>A final question: would people agree that we should start core/focused
> > >>(e.g., controller tier, view agnostic, not trying to define an entire
> > >>stack)? Seems like this is something that would help us move forward
> > >>more quickly, and would prevent us from trying to make too many leaf
> > >>nodes part of the trunk.
> > >>
> > >>
> > >>
> > >>>So what's next? Let's nail down the rules and then move on to a
> > >>>mission statement that we can announce. Remember: once we announce
> > >>>this, there's no going back, so let's spend some time on the rules
> > >>>and the mission statement. For now, please email back and forth any
> > >>>edits/additions to the rules.
> > >>>
> > >>>This is really exciting! Sorry for the long email and the (likely
> > >>>very) bureaucratic approach I'm taking with this -- I hope it adds
> > >>>some value.
> > >>>
> > >>>Patrick
> > >>>
> > >>>
> > >>
> > >>Exciting stuff!
> > >>
> > >>Rich
> > >>
> > >
> > >
> > >
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Web Framework Consolidation
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
Just a few opinions from the peanut gallery...
The era of the "classic" webapp is dead. Any new framework that doesn't
make it easy (well, EASIER anyway) to develop robust RIAs is dead on
arrival as far as I am concerned.
Further, I do not believe that the action-centric and component-centric
models need be exclusive of each other and in fact I believe that is the
natural evolution of things. I don't think this necessarily implies an
approach like bolting JSF onto Struts for example, but then again maybe
that is the most natural path. The real point though is the merging of
the two approaches into *something*, whatever that something winds up being.
So, if Clarity is going to take into consideration the building of RIAs
at its core, than I for one will be interested in how it evolves. IF
that isn't a central theme though, then it's DOA from my perspective.
All of the frameworks involved do many things right, so it would seem
logical to me that as long as you choose the things that work to merge,
the end result should be pretty good. I would start by getting input
from the community on what aspects of the contributing frameworks they
feel truly work and are must-haves for a next-generation framework.
Heck, the results of such a question could wind up being your goal
statement entirely :)
I would also make the point that Struts is the market leader for good
reason and so I would hope it isn't the fourth banana in the group.
Some people seem to believe that Struts is obsolete, or is rapidly
becoming so, is showing it's age, etc. I believe this is only the case,
if in fact it is, because it has been allowed to stagnate a bit in terms
of truly evolving. It has been on autopilot for way too long and other
frameworks have had a chance to pass it by. Be that as it may, the
point is that I believe for a new framework to be successful it should
take more cues from Struts on what TO do rather than what NOT to do.
Anything less is, IMO, foolishly ignoring the reputation and community
and success that Struts has enjoyed.
Those are my initial thoughts. In any case, I offer my sincerest Good
Luck in the endeavor, I'll be interested to see how it goes.
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM: fzammetti
Yahoo: fzammetti
MSN: fzammetti@hotmail.com
Don Brown wrote:
> Consolidation is a relatively unknown concept in the crowded web
> framework space. While most frameworks are open source allowing
> cross-pollination, collaboration is still rare resulting in duplicated
> efforts and confusion for the end user. Struts Ti, a next-gen project
> in the Struts sandbox, tried to buck the trend by building on WebWork
> rather than wasting its time writing yet another Model2 framework.
>
> Taking this level of cooperation to the next level, developers from four
> popular web frameworks - Struts, Spring, WebWork, and Beehive, have
> gotten together to discuss the possibility of consolidating their
> efforts into a new project, termed Clarity. Clarity would be an
> action-based MVC framework that combines the commonality of the four
> aforementioned frameworks into one that can be built upon by all.
>
> These discussions have just began, and while no one has "officially"
> signed on, I thought I should bring it before the Struts community for
> feedback. There is still much to work out, but I want to keep the
> community involved from the beginning.
>
> I personally am excited about this project and think it will be
> beneficial to users and developers alike. The Struts Classic code base
> is showing its age, but speaking as a developer who maintains old Struts
> apps, few people have the time and budget to rewrite them from scratch
> with a more disparate framework like Shale or Wicket. I think Clarity
> would be a much easier migration for existing Struts applications and
> developers, yet support key standards like Portlets and JSF.
>
> Attached is two messages in a private email thread between Patrick
> Lightbody (WebWork), Keith Donald (Spring), Rich Feit (Beehive), and me,
> that started the Clarity discussion. We plan to have a public email
> list for Clarity discussion, but it hasn't been setup yet.
>
> What I'm looking for from the Struts community is if you think this is a
> good idea, and if you do, what we need to do to make it work.
> Personally, I don't expect Struts or even Struts Classic going away at
> all even if we agreed Clarity is migration path, so this isn't an
> either/or discussion.
>
> Again, this is _NOT_ a project announcement meant for the world, only
> the beginning of a discussion about the idea of consolidating a few web
> frameworks and how Struts fits in with this. Looking forward to the
> comments,
>
> Don
>
> === Initial kickoff by Patrick Lightbody from WebWork ===
> Patrick Lightbody wrote:
> > (Warning: long email ahead. Don't worry, this isn't usually my style
> > and I'll stick to brief emails moving forward.)
> >
> > Hey guys -- this is the official "kickoff" of the project we've all
> > been talking about. Keith had a great code name for the project:
> Clarity.
> >
> > Before I get started, I just wanted to clarify the following people
> > involved and what their roles are:
> >
> > - Keith represents the Spring team, including the Spring MVC and
> > Spring WebFlow process. For now he will handle all the communication
> > between this project and the rest of the Spring folks.
> > - Jason is the primary technical representative from the WebWork team.
> > While I can add some info, I expect Jason will offer most of the
> > technical thoughts. Jason uses Spring and has a lot to offer here.
> > - Don Brown is a Struts committer and represents the Struts team (or
> > at least some of them). Don is the force behind Struts Ti and can
> > provide a lot of insight as user of WebWork and XWork, with both a
> > Struts and simplified "flavor" to it.
> > - Rich represents the Beehive team and also works on the Struts Ti
> > project. Rich will represent most of the Beehive input.
> > - Finally, I hope to, more than anything, act as a facilitator for
> > this whole project. Obviously I have a WebWork-slanted perspective, but
> > I believe that facilitating this process is more important than any set
> > of features or implementations choices.
> >
> > As I mentioned to you guys individually, I think the best way to move
> > forward is to take the following steps. I've taken a stab at the first
> > item as well.
> >
> > 1) Establish the rules: a small, agreed upon list of rules that we
> > promise to adhere to while working on this project. These will be
> > especially important in the early phases.
> >
> > 1) Complete a statement: we need to come up with a single paragraph
> > that sums up this effort. It should include the desire to work
> > together, the desire for clarity in the java web space, and the desire
> > to move beyond "petty" differences about implementation choices. In
> > short, this mission statement, when releases as a press release to the
> > entire community, should be powerful enough to get everyone excited
> > about it and know for sure that _this_ is the effort that will bring
> > web development productivity back to the Java camp.
> >
> > 2) Announce the project: we need to gather excitement around this as
> > soon as possible. Doing so will not only get us early feedback from the
> > community, it will most likely stave off a few more web frameworks from
> > being created (I found two more just today - eek!).
> >
> > 3) Set up a neutral place to host the project, including SVN, wiki, bug
> > tracker, etc. This place must be detached from Jakarta/Struts, Spring,
> > and OpenSymphony and must stay that way until we all feel comfortable
> > working together. That will likely happen about half way through
> step 4...
> >
> > 4) Now for the hard part: map out a technical implementation.
> >
> > 5) Release and re-establish Java as the place to build web
> > applications. I hope for this to happen within 8-12 months time,
> > starting today.
> >
> > So here are my ideal set of rules. Please adjust as you see fit:
> >
> > - Above all else, we recognize that consolidation is the overriding
> goal.
> > - We recognize that we'll all have to compromise on items we are
> > passionate about, but that the overall project success is more
> important.
> > - This project aims to unify WebWork, Struts, Spring MVC, Beehive, and
> > Spring WebFlow in to a single project that establishes clear leadership
> > in the web development space.
> > - All project leaders understand that once this project is releases,
> > future work their own projects should cease (other than supporting it,
> > minor releases, migration path to Clarity, etc).
> > - Technical disputes should be coordinated by those _least_ familiar
> > with the topic, and therefore least biased.
> > - When criticizing or proposing alternatives or otherwise "stopping
> > forward progress" - we promise to ask ourselves if this issue we're
> > about to raise is really "worth it".
> > - We recognize that not everyone works the way we do and we understand
> > that we may have to work hard to find common ground.
> >
> > So what's next? Let's nail down the rules and then move on to a mission
> > statement that we can announce. Remember: once we announce this,
> > there's no going back, so let's spend some time on the rules and the
> > mission statement. For now, please email back and forth any
> > edits/additions to the rules.
> >
> > This is really exciting! Sorry for the long email and the (likely very)
> > bureaucratic approach I'm taking with this -- I hope it adds some
> value.
> >
> > Patrick
>
> === Keith Donald from Spring Web Flow/MVC ===
>
> Keith Donald wrote:
> > I think a good first step is to clearly state what we all expect to
> gain out
> > of working together, given the dynamics of this market, and what our
> > individual expectations are:
> >
> > Here's my take:
> > --------------
> > If you look at the open source web framework market, I see these camps:
> >
> > 1. Action-centric (Struts Classic, Struts Ti, Spring MVC, WW, SWF,
> Beehive)
> > 2. Component-centric (JSF-based <Struts Shale, JBoss Seam>, Tapestry,
> > Wicket, Echo)
> > 3. Ruby on Rails
> >
> > Options in camps #2 and #3 represent considerable more shock to adopt
> than
> > those in #1. This is for various reasons, but mainly because the
> majority
> > of the market (existing Struts users) can more naturally migrate to the
> > other action-centric frameworks. Spring MVC, for example, has been
> > positioned as a more extensible Struts and that strategy has proven
> fairly
> > effective. Spring Web Flow, is usable as a component from within both
> > Struts classic and Spring MVC, and that too has proven effective.
> Beehive
> > is built on Struts.
> >
> > So there is definite overlap (and some compliment, too) between Struts,
> > Spring MVC, WW, SWF, and Beehive, and I think it's fair to say we share
> > similar goals for tackling the same problems. Because of this, there
> is a
> > natural fit for consolidation/collaboration, motivated more now by two
> > external forces:
> >
> > 1. Camps #2 and #3 are threats. RoR is one, JBoss Seam is another.
> >
> > 2. The market is fragmented, and that creates user confusion. There
> is no
> > clear "next paradigm" <is JSF the base for that or not?>, and that
> creates
> > (encourages?) opportunity for new entrants with little invested thus
> far to
> > jump in and steal the show (look what Seam is trying to do, and the
> RoR hype
> > coming from high-profile independents in the Java community).
> >
> > --
> >
> > So the "clarity" project in my mind should be about providing a clear
> "next"
> > choice in the web-space for the Struts Classic, TI, WW, Beehive, and
> Spring
> > communities, with the premise being we'd be a lot stronger together
> than we
> > would competing with one another in essentially similar (but slightly
> > different) ways.
> >
> > From my perspective, I think it's important to market a full-stack
> product,
> > "clarity", which unites our respective brands/technologies; however,
> I feel
> > it's just as important that such a stack be built from a set of
> > best-of-breed components that lends itself to choice. For example, we
> > wouldn't want to just ignore JSF, it's not going away (and that is
> exactly
> > why Spring has made JSF integration a high priority, integrating SWF
> as a
> > more powerful JSF NavigationHandler).
> >
> > The ultimate goal, though, would be to win on the full-stack, the
> "clarity"
> > brand, appealing to a message of simplicity comparable to RoR but
> without
> > the shock.
> >
> > Interface21 would be willing to fund marketing and technical effort
> behind
> > this (including hosting infrastructure), hopefully with the support
> of BEA
> > as well.
> >
> > --
> >
> > From Spring's perspective there are a couple of expectations/issues I
> want
> > to get out there:
> >
> > - Spring in general has moved from being the gem of the technology
> > enthusiasts to more of a rock for the pragmatists (early majority).
> This is
> > more of the case for Spring's middle ware stack (IoC/TX/DAO/etc), but
> Spring
> > MVC also applies to some degree as it is shipped with the core
> framework.
> > Among other things, this means Interface21 and BEA are now in the
> business
> > of providing Spring support/training/certification, and that entails
> > contractual obligations for supporting existing versions of Spring.
> So work
> > on any part of the framework just can't stop on a dime: we must
> continue to
> > support our customers. Backwards compatibility, as well as the
> ability to
> > run on existing infrastructure <JDK 1.3 or >), is very important to
> us for
> > this reason.
> >
> > With that said, however, we do expect more support work around Spring's
> > middle ware stack, as it is more widely used than Spring MVC. So we
> do have
> > more flexibility for change with Spring MVC, but we just can't stop
> > supporting it. Likewise, we'd want a "clarity" migration from Spring
> MVC to
> > be as easy as possible.
> >
> > I think ease of adoption is important to all of us, else our own
> communities
> > may turn on us.
> >
> > - Spring Web Flow represents a major investment for us in the last year.
> > We've put much more resources into SWF than we have MVC, as MVC has
> always
> > been a foundation to build on while SWF is a full-featured page flow
> > product. SWF is also at a different place in the market than MVC: as
> a new
> > product positioned as a breakthrough technology, it is the gem of the
> > enthusiast at this point. We expect when it reaches 1.0 it will become
> > widely adopted quickly, as it has considerable momentum now, and is well
> > positioned.
> >
> > Given that, I see opportunity with Clarity to capitalize on synergy
> between
> > SWF and Beehive PF and also leverage the momentum of SWF's
> approaching 1.0
> > release. I do have concerns of dilution: we wouldn't want to dilute the
> > effort/branding we've put into SWF, and risk losing the momentum we
> have now
> > (or worse, giving it away to say JBoss Seam, who is trying to play
> catchup
> > with both of us).
> >
> > What I'm saying is SWF is going to be successful on its own, as a new
> > product addressing an untapped niche, so we want to make sure we take
> > advantage of that with Clarity without dilution... and do so quickly,
> before
> > other competitors have a chance to stake a claim by copying it and
> making
> > the clone a part of their "full stack".
> >
> > --
> >
> > I hope this provides some insight into where Spring is coming from
> and our
> > interest with Clarity. I feel this is unique opportunity to come
> together
> > and leverage the best in each of our respective products, and unite our
> > communities under a common brand whose development is sustained not
> only by
> > open source developers but commercial companies such as Interface21
> and BEA
> > as well.
> >
> > Once we have it out in the open what we all hope to gain, I think a good
> > next step is to start flushing out from a technical perspective what
> this
> > thing would look like--in the ideal, and keeping in mind migration
> from our
> > existing products, and the need for components at each key part in the
> > stack. Once the technical architecture is understood, then I think it's
> > natural to start focusing on marketing/branding.
> >
> > Keith
> >
> > -----Original Message-----
> > From: Patrick Lightbody [mailto:plightbo@gmail.com]
> > Sent: Thursday, October 06, 2005 11:20 AM
> > To: Rich Feit
> > Cc: Keith Donald; Don Brown; Jason Carreira
> > Subject: Re: Project Clarity Kickoff
> >
> > Rich,
> > Yes, the project of course would be open source and likely Apache 2.0
> > License.
> >
> > I agree: Our mission statement must give a high level detail of the
> > project as well, clarifying the space.
> >
> > I also think the wikis/infrastructure should be open.
> >
> > As for technical details (step #4), when we get there we will
> > definitely focus on framework features and characterization. I just
> > don't want to dive in to these things yet - as some topics can and
> > will be very contentious. That's why I'm avoiding a reply to Jason's
> > email :)
> >
> > You're right -- that rule about "stopping the other projects" is
> > simply there to make sure that we all understand that competing
> > efforts would be ramped down. I think we all know that, so it may not
> > even be worth stating.
> >
> > Patrick
> >
> > On Oct 6, 2005, at 12:21 AM, Rich Feit wrote:
> >
> >
> >>Patrick,
> >>
> >>This *is* really exciting -- if Clarity comes about, it'll cut through
> >>the confusion that's starting to dominate this space.
> >>
> >>I think you're setting this up really well. I have a few specific
> >>comments, but my first is this: before I could commit Beehive to the
> >>project, I have to be able to share it with the Beehive community,
> >>even
> >>at this early stage. Some kind of message that says a bunch of key
> >>projects want to consolidate to eliminate overlap, and that this would
> >>supplant a chunk of Beehive. Committers vote, possibly tell me to
> >>go to
> >>hell. I assume this isn't a problem, but I want to make sure it's out
> >>there. (Don, I guess you're in the same boat...?)
> >>
> >>Some specifics inline...
> >>
> >>Patrick Lightbody wrote:
> >>
> >>
> >>
> >>>(Warning: long email ahead. Don't worry, this isn't usually my style
> >>>and I'll stick to brief emails moving forward.)
> >>>
> >>>Hey guys -- this is the official "kickoff" of the project we've all
> >>>been talking about. Keith had a great code name for the project:
> >>>Clarity.
> >>>
> >>>Before I get started, I just wanted to clarify the following people
> >>>involved and what their roles are:
> >>>
> >>> - Keith represents the Spring team, including the Spring MVC and
> >>>Spring WebFlow process. For now he will handle all the communication
> >>>between this project and the rest of the Spring folks.
> >>> - Jason is the primary technical representative from the WebWork
> >>>team. While I can add some info, I expect Jason will offer most of
> >>>the technical thoughts. Jason uses Spring and has a lot to offer
> >>>here.
> >>> - Don Brown is a Struts committer and represents the Struts team
> >>>(or
> >>>at least some of them). Don is the force behind Struts Ti and can
> >>>provide a lot of insight as user of WebWork and XWork, with both a
> >>>Struts and simplified "flavor" to it.
> >>> - Rich represents the Beehive team and also works on the Struts Ti
> >>>project. Rich will represent most of the Beehive input.
> >>> - Finally, I hope to, more than anything, act as a facilitator for
> >>>this whole project. Obviously I have a WebWork-slanted perspective,
> >>>but I believe that facilitating this process is more important than
> >>>any set of features or implementations choices.
> >>>
> >>>As I mentioned to you guys individually, I think the best way to move
> >>>forward is to take the following steps. I've taken a stab at the
> >>>first item as well.
> >>>
> >>>
> >>
> >> 0) Agree on the software license. Without the right license
> >>(ASF),
> >>I'm guessing many of us wouldn't be able to participate.
> >>
> >>Also, a basic question. Is this an open source project?
> >>
> >>
> >>
> >>>1) Establish the rules: a small, agreed upon list of rules that we
> >>>promise to adhere to while working on this project. These will be
> >>>especially important in the early phases.
> >>>
> >>>1) Complete a statement: we need to come up with a single paragraph
> >>>that sums up this effort. It should include the desire to work
> >>>together, the desire for clarity in the java web space, and the
> >>>desire to move beyond "petty" differences about implementation
> >>>choices. In short, this mission statement, when releases as a press
> >>>release to the entire community, should be powerful enough to get
> >>>everyone excited about it and know for sure that _this_ is the effort
> >>>that will bring web development productivity back to the Java camp.
> >>>
> >>>
> >>
> >>Totally. The only thing I'd add here (maybe obvious) is that this
> >>should go beyond the desire to work together and bring clarity to the
> >>space -- some high-level characterization of what the framework itself
> >>is about.
> >>
> >>
> >>
> >>>2) Announce the project: we need to gather excitement around this as
> >>>soon as possible. Doing so will not only get us early feedback from
> >>>the community, it will most likely stave off a few more web
> >>>frameworks from being created (I found two more just today - eek!).
> >>>
> >>>3) Set up a neutral place to host the project, including SVN, wiki,
> >>>bug tracker, etc. This place must be detached from Jakarta/Struts,
> >>>Spring, and OpenSymphony and must stay that way until we all feel
> >>>comfortable working together. That will likely happen about half way
> >>>through step 4...
> >>>
> >>>
> >>
> >>It would be as open as the wikis, mailing lists, repositories, etc. of
> >>the rest of the projects, right?
> >>
> >> [additional item -- maybe falls under #4] Agree on general features
> >>and characteristics of the framework. Some examples (note: I'm not
> >>assuming everyone would agree to these particular ones :) ):
> >> - support entities that are flow controllers as first class
> >>citizens
> >> - support the association of per-user state with a flow controller
> >> - allow Java 5 annotations as a way to configure controllers
> >> - provide a fast no-redeploy iterative dev experience
> >>
> >> [additional item -- maybe falls under #4] Mock up some files/
> >>artifacts
> >>as the user would see/write them. Like what Don did early on in Ti
> >>(http://wiki.apache.org/struts/StrutsTi/ControllerMock ).
> >>
> >>
> >>
> >>
> >>>4) Now for the hard part: map out a technical implementation.
> >>>
> >>>5) Release and re-establish Java as the place to build web
> >>>applications. I hope for this to happen within 8-12 months time,
> >>>starting today.
> >>>
> >>>So here are my ideal set of rules. Please adjust as you see fit:
> >>>
> >>> - Above all else, we recognize that consolidation is the overriding
> >>>goal.
> >>> - We recognize that we'll all have to compromise on items we are
> >>>passionate about, but that the overall project success is more
> >>>important.
> >>> - This project aims to unify WebWork, Struts, Spring MVC, Beehive,
> >>>and Spring WebFlow in to a single project that establishes clear
> >>>leadership in the web development space.
> >>> - All project leaders understand that once this project is
> >>>releases,
> >>>future work their own projects should cease (other than supporting
> >>>it, minor releases, migration path to Clarity, etc).
> >>> - Technical disputes should be coordinated by those _least_
> >>>familiar
> >>>with the topic, and therefore least biased.
> >>> - When criticizing or proposing alternatives or otherwise "stopping
> >>>forward progress" - we promise to ask ourselves if this issue we're
> >>>about to raise is really "worth it".
> >>> - We recognize that not everyone works the way we do and we
> >>>understand that we may have to work hard to find common ground.
> >>>
> >>>
> >>
> >> The rules... I agree, for us to succeed, we need these. We'll all
> >>have to take as a prime goal compromise/progress over dogma. My main
> >>comment is about consolidation and ceasing development on the ancestor
> >>projects. Beehive has components that I assume are far outside the
> >>mission of Clarity (e.g., JSR 181 Web Services Metadata
> >>implementation). Just want to make sure we're not trumpeting the
> >>death
> >>of entire frameworks that don't overlap. Relatedly, I feel that the
> >>cease-development clause should go something like this:
> >> "... will cease developing features that overlap with features
> >>in Clarity."
> >> It's clearly not in the interest of any project to keep plugging
> >>along with a redundant framework (c'mon, how can you compete with
> >>Clarity? :) ), but I imagine that many features will fall outside the
> >>scope of what's done here.
> >>
> >>A final question: would people agree that we should start core/focused
> >>(e.g., controller tier, view agnostic, not trying to define an entire
> >>stack)? Seems like this is something that would help us move forward
> >>more quickly, and would prevent us from trying to make too many leaf
> >>nodes part of the trunk.
> >>
> >>
> >>
> >>>So what's next? Let's nail down the rules and then move on to a
> >>>mission statement that we can announce. Remember: once we announce
> >>>this, there's no going back, so let's spend some time on the rules
> >>>and the mission statement. For now, please email back and forth any
> >>>edits/additions to the rules.
> >>>
> >>>This is really exciting! Sorry for the long email and the (likely
> >>>very) bureaucratic approach I'm taking with this -- I hope it adds
> >>>some value.
> >>>
> >>>Patrick
> >>>
> >>>
> >>
> >>Exciting stuff!
> >>
> >>Rich
> >>
> >
> >
> >
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Web Framework Consolidation
Posted by Don Brown <mr...@apache.org>.
Again, the requirements haven't been nailed down, but one of the main
interests is to combine beehive's page flow and spring's web flow in
some way. I think it is fair to say stateless actions are a thing of
the past.
Don
Michael Jouravlev wrote:
> Any chance for these actions to be stateful (as in Struts Dialogs)?
> Any need for single-page multi-panel wizards to complement multi-page
> Spring flows?
>
> Seems that flows/wizards topic gets popular. Beehive, Ti and Spring
> offers some sort of support for it. Is it already decided how the
> occupation zones will be chosen?
>
> Michael J.
>
> On 10/10/05, Don Brown <mr...@twdata.org> wrote:
>
>>Clarity would be an
>>action-based MVC framework that combines the commonality of the four
>>aforementioned frameworks into one that can be built upon by all.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Web Framework Consolidation
Posted by Michael Jouravlev <jm...@gmail.com>.
Any chance for these actions to be stateful (as in Struts Dialogs)?
Any need for single-page multi-panel wizards to complement multi-page
Spring flows?
Seems that flows/wizards topic gets popular. Beehive, Ti and Spring
offers some sort of support for it. Is it already decided how the
occupation zones will be chosen?
Michael J.
On 10/10/05, Don Brown <mr...@twdata.org> wrote:
> Clarity would be an
> action-based MVC framework that combines the commonality of the four
> aforementioned frameworks into one that can be built upon by all.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Web Framework Consolidation
Posted by Ted Husted <te...@gmail.com>.
I tried to make this post shorter, but this is the best I could do :(
Patrick Lightbody wrote:
> Above all else, we recognize that consolidation is the overriding goal.
IMHO, for a consolidation project to succeed beyond the scope of
enthusiasts, a migration path has to be a primary objective. Will
projects like JIRA and Confluence be able to migrate from WebWork to
Clarity, without starting over? Will Oracle and WebSphere be able to
migrate their tools from Struts to Clarity, without starting over?
Ditto for Landsend and Citibank and hundreds (or thousands) of other
non-trivial applications?
If our goal is to consolidate not only the development base but the
user base, then we must be sure that significant, non-trivial
applications can "get there from here". The importance of a migration
path cannot be understated. I would suggest that migration be part of
the mission statement.
Of course, Clarity should not be shackled by the tyranny of the
installed base (as is Struts Classic). We should not have to make too
many compromises for the sake of backward compatability. Somehow, a
balance must be struck.
Patrick Lightbody wrote:
> All project leaders understand that once this project is releases, future work their own projects should cease
> (other than supporting it, minor releases, migration path to Clarity, etc).
One way to view a migration path is converting an application in a
fell swoop. Another way to view a migration path is evolving an
application, step by step. If we know that Clarity is the end,
prexisting projects can march applications toward that end, using a
proven deprecate/release/remove cycle. Rather than view existing
projects as "legacies" to be discarded, perhaps we could view them as
"stepping stones" that will lead us all to Clarity, feature by
feature.
We should recognize that getting projects from "here to there" is not
something that will take months. Realistically, migration is a process
that will take several years for most people. We should recognize that
reality and plan for it.
We must recognize that teams are not going to jump ship just because
we jump first. (Witness JSF.) Rather than desert proven solutions, we
must be ready to set a course and steer each ship to a common port. It
will take time, but we have time -- if we don't try to rush people.
Internet time is dead. Most teams are living in enterprise time now,
with product cycles that span several years, not a handful of months.
After investing several years of development into Struts or WebWork or
Spring MVC, prudent product managers are not going to choose something
else without a clear migration path. Sun itself has been trying to do
just that. How can any other group hope to succeed where Sun is not,
unless we take the time to build gentle ramps to our unified platform?
Patrick Lightbody wrote:
> This place must be detached from Jakarta/Struts, Spring, and OpenSymphony
> and must stay that way until we all feel comfortable working together.
To complete the initial planning, neutral ground sounds like a good
idea. If there's interest, we could setup an independant Confluence
space for Clarity that can be as public or private as we like. The
space provided by Atlassian and is not affiliated with the ASF.
* http://opensource2.atlassian.com/confluence/oss/
You know, the OO modeling community faced a similar problem ten years
ago. As Martin Fowler puts it in "UML Distilled" :
"The same basic concepts would appear in very different notations,
which caused confusion" ... "Talk of standardization had surfaced, but
nobody seemed willing to do anything about it".
There were some independant attempts at standardization, which failed.
Then, the marketplace leaders -- the "three amigos:" Brooch, Jacobson,
and Rumbaugh -- got together and defined UML, which went on to become
an OMG standard (in not-so-painless process).
It seems like the same thing is starting to happen again, except here
we have the four musketeers -- Beehive, Spring, Struts, and WebWork --
riding out to save the day :)
Personally, I would suggest that Clarity not stay an "independant"
project too long. No matter what we say about "legacy" projects and
"clear choices", as an independant project Clarity *will* be viewed as
a third alternative to Struts Classic or JSF. This is an inevitable
marketplace dynamic, and there is nothing anyone can do to avoid it.
When the time comes, Clarity should seriously consider whether it
would like to be a Struts product. By adopting Shale and considering
TI, Struts has shown that we consider the project to be more than the
direct descendant of Craig's Action package.
As a Struts product, Clarity would have immediate access to thousands
of teams that have already obtained approval to use Struts. As an
independant, many teams will have to wait months or even years to get
Clarity on the approved software list. Getting on the short list is a
painful process in many enteprises, and a key reason why more teams
are not already using Spring. (Gotta love Spring!)
If it is the users and the marketplace that Clarity cares about, then
the best thing for the marketplace would be to leverage the very
strong brand that Struts already offers. The Struts brand is arguably
as strong, or stronger, than all the other brands combined. If we
circle the wagons around Apache Struts, we will have the opportunity
to not only build something better than Struts, WebWork, or Spring MVC
ever could be, but we will have a ready-made distribution channel
waiting for us when we are done.
By playing to our strengths, it will be much easier for users to
perceive Clarity as *the* unified, single-source alternative to .NET
or PHP or Ruby.
Once upon a time, we talked about making Stuts 2.x a "best of breeds"
framework. We talked about adopting and adapting the best ideas from
the other frameworks and creating a brave, new framework that better
met all of our needs. Putting all the marketplace mumbo-jumbo aside, I
think that's what Clarity wants too. There will probably never be a
Struts Classic 2.x, but, if we are willing, there could be a Struts
Clarity 1.x.
Patrick Lightbody wrote:
> 4) Now for the hard part: map out a technical implementation.
The first three technical questions I'd be asking about Clarity are
(1) What services should a web application framework provide? What are
our Use Cases?
* http://opensource2.atlassian.com/confluence/oss/display/STRUTS/Use+Cases
(2) Which of these Use Cases are being solved by existing frameworks?
For each of these cases, is one of the existing solutions clearly more
effective than the alternatives?
(3) Which of these Use Cases are not being solved, or solved well, by
existing frameworks?
-- HTH, Ted.
http://www.husted.com/poe/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Web Framework Consolidation
Posted by Ted Husted <te...@gmail.com>.
While Clarity make other decisions regarding infrastructure, it might
be a good idea for one of the key Clarity contacts to setup a
QuickTopic to discuss Patrick's post.
* http://quicktopic.com/
Just the thing for something like this!
In the meantime, I'll start a new thread here, with a [Clarity] tag,
so people can apply the usual filtering techniques.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org