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
--- Begin Message ---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 theproject, I have to be able to share it with the Beehive community, evenat this early stage. Some kind of message that says a bunch of key projects want to consolidate to eliminate overlap, and that this wouldsupplant a chunk of Beehive. Committers vote, possibly tell me to go tohell. 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:0) Agree on the software license. Without the right license (ASF),(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 ofthe technical thoughts. Jason uses Spring and has a lot to offer here. - Don Brown is a Struts committer and represents the Struts team (orat 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.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/ artifactsas 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_ familiarwith 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 Metadataimplementation). Just want to make sure we're not trumpeting the deathof 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. PatrickExciting stuff! Rich
--- End Message ---
--- Begin Message ---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
--- End Message ---
