beehive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daryl Olander <dolan...@gmail.com>
Subject Re: Beehive/Spring/Struts/WebWork
Date Mon, 10 Oct 2005 20:18:54 GMT
Pulling from the mail below to summerize (emphasis is mine):

From: Patrick Lightbody <plightbo@gmail.com>
To: Rich Feit <richfeit@gmail.com>
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 <richfeit@gmail.com> 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 <plightbo@gmail.com>
> To: Rich Feit <richfeit@gmail.com>
> 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" <keith@interface21.com>
> To: "Rich Feit" <richfeit@gmail.com>
> 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:richfeit@gmail.com]
> >>>>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
>
>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message