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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
> >>
> >>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:[EMAIL PROTECTED]
> >>> > 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: [EMAIL PROTECTED]
> >>>For additional commands, e-mail: [EMAIL PROTECTED]
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: [EMAIL PROTECTED]
> >>For additional commands, e-mail: [EMAIL PROTECTED]
> >>
> >>
> >>
> >>
> >
> >
> >--
> >"You can lead a horse to water but you cannot make it float on its back."
> >~Dakota Jack~
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: [EMAIL PROTECTED]
> >For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to