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]
