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]

Reply via email to