Pulling from the mail below to summerize (emphasis is mine): From: Patrick Lightbody <[EMAIL PROTECTED]> To: Rich Feit <[EMAIL PROTECTED]> Date: Thu, 6 Oct 2005 08:20:02 -0700 Subject: Re: Project Clarity Kickoff
... 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. ... On 10/10/05, Rich Feit <[EMAIL PROTECTED]> wrote: > > Hi all, > > I've been on a bunch of emails about the idea of a new web framework that > would somehow unify Beehive, Spring, Struts and WebWork -- at least the > parts of all these projects that overlap. As far as I know, none of these > groups has officially signed onto any such idea, and the parameters of the > project definitely have not been hashed out yet. I'm wondering what sorts of > reactions people here have to the idea at this stage. If it happens, should > Beehive be involved? Are there parameters that would make this a good thing > for Beehive to join? > > We had a brief exchange about this on the PMC this weekend, mostly to > confirm that it's a discussion that we should have on this list. So here we > are. > > Some notes: > > - I'm attaching the initial email I got from Patrick Lightbody (WebWork), > along with another from Keith Donald (Spring). I forwarded the entire chain > to the PMC and it was apparently overwhelming and of marginal value, so I'll > try to limit it to important messages. > > - I want to stress that *if* this is something we should be a part of, > then it is up to us (the Beehive community) to establish the ways in which > we would need this to work. Other projects will have other opinions/needs. > If we do this, I think that scoping the project and setting it up will be > the hardest parts. > > - I am currently on a private thread with four other people about this. As > you'll see from the original email, they're trying to keep the discussion > limited to one representative from each project until there's resolve to go > forward with it. I'm actually in favor of the project -- I think it would be > good for Beehive and for the community at large -- but as this discussion > shapes up, I would like to be replaced by someone who's more skeptical. I > think this will help us move forward (the whole Nixon/China thing :) ). > > - The attached email from Keith is a technical exchange he and I had about > how Beehive Page Flow and Spring Web Flow could be integrated. One of our > PMC members expressed concern about this, so I wanted to include it and to > assert that this isn't committing us to anything. It was meant to be an > exploration of whether we could work together, and I think it's enough to > show that we can. For now, I'll drop this discussion until we have a clearer > idea of Beehive's involvement. > > It's really important that we figure out if (and *how*) this would work > for Beehive. Let me know what you think. > > Thanks, > Rich > > > > > ---------- Forwarded message ---------- > From: Patrick Lightbody <[EMAIL PROTECTED]> > To: Rich Feit <[EMAIL PROTECTED]> > Date: Thu, 6 Oct 2005 08:20:02 -0700 > 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 > > > > > > > > ---------- Forwarded message ---------- > From: "Keith Donald" <[EMAIL PROTECTED]> > To: "Rich Feit" <[EMAIL PROTECTED]> > Date: Sun, 9 Oct 2005 13:32:32 -0500 (CDT) > Subject: Re: Project Clarity Kickoff > Rich, > > I imagine I'm missing something in Beehive's case, but in SWF's case: > > - For the XML flow definition format, DTD validation catches "compile > time" errors quite nicely. Supplimented with a flow editor, like what the > Spring IDE team is working on, and you can do more of course, but plain > old DTD validation takes care of the most common 80% for sure. > > - At runtime, an out-of-container test of the Flow execution catches any > runtime logic errors in the flow, allowing you to test all paths through > the flow from a JUnit test. So you can code your flow, run the test, see > it fail, revise, run the test, see it fail again, revise, run the test, > see *green bar* ... then deploy the flow for execution in container. > > For an annotation-driven format, the Java 5 compiler would catch most > errors, as well, right? What other compile-time processing happens beyond > what the compiler does? > > Keith > > > Excellent. Yeah, as things progress, people aren't going to accept > > anything less than a kickass iterative dev experience. I do think that > > #1 is just as important, though; it allows you to see all errors and > > warnings in the entire app. If it "compiles" fully, then you've got > > something that won't blow up at runtime (or, the blowups are confined to > > logic errors). You also have a more transparent translation of the > > annotations into something the runtime will consume. I'd just propose > > that we do both. The annotation processing layer is the most known > > quantity here; getting the runtimes to match up will be the core of the > > work. > > > > Rich > > > > Keith Donald wrote: > > > >>Cool! I look forward to helping you work through this. > >> > >>You probably already know this, but just in case: SWF has no buildtime > >>step. Rather, flow definitions represented in Xml or Java are parsed > >> into > >>configured org.springframework.webflow.Flow instances by their > respective > >>FlowBuilder implementation at runtime. > >> > >>Once you have a configured webflow.Flow, you have everything, as that is > >>the core object in the system. More specifically, with a webflow.Flow in > >>hand you can then create a FlowExecution which represents *exactly one* > >>user conversation (implemented internally as a finite state machine) and > >>start signaling events against it. > >> > >>As you mention, our customers really like this because it lends it self > >> to > >>agile/iterative development. There is no special code generation / > >>compilation step, and it is straightforward to add support for > >>hot-reloadable flows. In addition, FlowExecutions are extremely natural > >>to test. > >> > >>So I would certainly favor determing the feasibility of option #2 as a > >>priority over option #1. > >> > >>Keith > >> > >> > >> > >>>I agree -- I'm sure there would be some obstacles to clear (impedance > >>>mismatch in some areas), but it would be a great place to start. > >>> > >>>Assuming that a Beehive page flow could be expressed as a SWF Flow, I > >>>see two main ways to build the Flow: > >>> 1) At build time, when running under apt (or XDoclet -- we can > >>>support both). In this case I think we'd just generate to your XML > >>>format. > >>> 2) At runtime, where the Page Flow checker/generator would run in a > >>>FlowBuilder. This would be great for iterative dev. > >>> > >>>I think this is definitely worth exploring. > >>> > >>>Rich > >>> > >>>Keith Donald wrote: > >>> > >>> > >>> > >>>>If a Beehive PF could be straightforwardly engineered into a SWF Flow > >>>>definition (an instance of the class org.springframework.webflow.Flow > ), > >>>>that > >>>>would be a natural integration point. > >>>> > >>>>SWF has a very complete API for expressing a Flow (rich with behavior > >>>> as > >>>>well, not just data). It also includes a pluggable FlowBuilder > >>>> strategy > >>>>for > >>>>to constructing those Flow definitions. Current implementations > >>>> support > >>>>construction from a XML definition, Java code, or a Groovy script > >>>>(org.springframework.webflow.config.FlowBuilder's class hierarchy for > >>>>details). > >>>> > >>>>Does a BeehiveFlowBuilder that builds a Flow from an annotated > JavaBean > >>>>make > >>>>sense? That seems quite ideal, as we could leverage the flexible > >>>>architecture of SWF with the existing toolability/compatability of the > >>>>Beehive PF format. > >>>> > >>>>Keith > >>>> > >>>>-----Original Message----- > >>>>From: Rich Feit [mailto:[EMAIL PROTECTED] > >>>>Sent: Saturday, October 08, 2005 12:16 PM > >>>>To: Keith Donald > >>>>Cc: 'Don Brown'; 'Patrick Lightbody'; 'Jason Carreira' > >>>>Subject: Re: Project Clarity Kickoff > >>>> > >>>>Keith Donald wrote: > >>>> > >>>> > >>>> > >>>> > >>>> > >>>>>>I'd like to see Clarity be > >>>>>>"more Shale than Shale", in providing a strong controller that > >>>>>>compliments > >>>>>>JSF, yet can work with other view technologies. > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>Exactly, I totally agree. We also have JSF/SWF integration examples, > >>>>>and > >>>>>Craig has been helping Colin and I with the integration (which is > >>>>> moving > >>>>>along nicely). > >>>>> > >>>>>Beehive and SWF--how can the two be combined? > >>>>> > >>>>>Keith > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>If Beehive is a part of Clarity, then I imagine this would be the > >>>>hardest integration task. But I've been looking at SWF, and I think > >>>>it's possible that (some modification of) Beehive Page Flow could be > >>>>built on (some modification of) Spring Web Flow. After all, much of > >>>>Page Flow is about annotated JavaBeans that encapsulate flow/state. > >>>>This isn't incompatible with SWF's way of doing things -- possibly an > >>>>optional layer above it. > >>>> > >>>>Accomplishing this would take some sincere effort (and compromise) > from > >>>>both sides, but it's likely doable. > >>>> > >>>>Rich > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >> > >> > >> > >> > > > > > -- > Keith Donald > Principal Consultant, Interface21 > http://www.springframework.com - Spring Services From the Source > > > >
