Mailing-List: contact dev-help@struts.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Struts Developers List" <dev@struts.apache.org>
Received-SPF: pass (asf.osuosl.org: domain of dakota.jack@gmail.com designates
 64.233.162.202 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=tB947gZcEuwyCcPsFOyT+vTkp2goucZhMUJRFGkpYI6FSdiOHLLkx2yJ5KR24axlKSNcrbReJM0AOcnuub2N2seD3f+Wt/B0YMnhEpkCJM3DpypB4M981W8XE4PouVp0dz9LSfmc/0nJMIfOQFuGo/Z/eCfPWeiWQqoGEyuyfK8=
Message-ID: <e03014300510151727n7e93bf28g1b9e2b2c0a97169e@mail.gmail.com>
Date: Sat, 15 Oct 2005 17:27:59 -0700
From: Dakota Jack <dakota.jack@gmail.com>
To: Struts Developers List <dev@struts.apache.org>, fzlists@omnytex.com
Subject: Re: Web Framework Consolidation
In-Reply-To: <434AF0DB.5020004@omnytex.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <434AC6EE.90205@twdata.org> <434AF0DB.5020004@omnytex.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 <fzlists@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 bei=
ng.
>
> 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 fou=
r
> > 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 bas=
e
> > is showing its age, but speaking as a developer who maintains old Strut=
s
> > 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
> >
> > =3D=3D=3D Initial kickoff by Patrick Lightbody from WebWork =3D=3D=3D
> > 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  t=
eam.
> >  > 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 mov=
e
> >  > forward is to take the following steps. I've taken a stab at the  fi=
rst
> >  > 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  des=
ire
> >  > 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 brin=
g
> >  > 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,  Spri=
ng,
> >  > and OpenSymphony and must stay that way until we all feel  comfortab=
le
> >  > 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  leader=
ship
> >  > in the web development space.
> >  >  - All project leaders understand that once this project is  release=
s,
> >  > 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_  famili=
ar
> >  > 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  unders=
tand
> >  > 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  mis=
sion
> >  > 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 th=
e
> >  > 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  v=
ery)
> >  > bureaucratic approach I'm taking with this -- I hope it adds  some
> > value.
> >  >
> >  > Patrick
> >
> > =3D=3D=3D Keith Donald from Spring Web Flow/MVC =3D=3D=3D
> >
> > 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 cam=
ps:
> >  >
> >  > 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 adop=
t
> > 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 bo=
th
> >  > 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 Stru=
ts,
> >  > Spring MVC, WW, SWF, and Beehive, and I think it's fair to say we sh=
are
> >  > similar goals for tackling the same problems.  Because of this, ther=
e
> > is a
> >  > natural fit for consolidation/collaboration, motivated more now by t=
wo
> >  > 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 clea=
r
> > "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 slightl=
y
> >  > 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), bu=
t
> > 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 Sprin=
g'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 Sprin=
g
> > 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 y=
ear.
> >  > 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: a=
s
> > a new
> >  > product positioned as a breakthrough technology, it is the gem of th=
e
> >  > enthusiast at this point.  We expect when it reaches 1.0 it will bec=
ome
> >  > 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 ne=
w
> >  > product addressing an untapped niche, so we want to make sure we tak=
e
> >  > 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 t=
he
> >  > 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 no=
t
> >  > 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 throu=
gh
> >  >>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 wou=
ld
> >  >>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 o=
ut
> >  >>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 styl=
e
> >  >>>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 communicatio=
n
> >  >>>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 mo=
ve
> >  >>>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 effo=
rt
> >  >>>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 th=
e
> >  >>space -- some high-level characterization of what the framework itse=
lf
> >  >>is about.
> >  >>
> >  >>
> >  >>
> >  >>>2) Announce the project: we need to gather excitement around this a=
s
> >  >>>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 wa=
y
> >  >>>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 feature=
s
> >  >>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 controll=
er
> >  >>    - 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 overridin=
g
> >  >>>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 "stoppin=
g
> >  >>>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 al=
l
> >  >>have to take as a prime goal compromise/progress over dogma.  My mai=
n
> >  >>comment is about consolidation and ceasing development on the ancest=
or
> >  >>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 featur=
es
> >  >>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 th=
e
> >  >>scope of what's done here.
> >  >>
> >  >>A final question: would people agree that we should start core/focus=
ed
> >  >>(e.g., controller tier, view agnostic, not trying to define an entir=
e
> >  >>stack)?  Seems like this is something that would help us move forwar=
d
> >  >>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