You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@beehive.apache.org by Rich Feit <ri...@gmail.com> on 2005/10/10 20:36:56 UTC
Beehive/Spring/Struts/WebWork
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
Re: Beehive/Spring/Struts/WebWork
Posted by Rich Feit <ri...@gmail.com>.
Hi all,
As you know, the discussion about framework consolidation has been going
on in a private thread among four people. It's understandable that in
order to move forward on defining goals, requirements, etc., this can't
be expanded to include the entirety of all four dev communities
(hundreds of people). For Beehive to be involved, though, there needs
to be wider coverage -- I don't believe it's possible for one person to
represent us adequately. Given this, I'd like to propose that Daryl and
Eddie be added as representatives of Beehive on the thread. The job of
all the representatives would be to engage in the discussions, report on
them, and of course come back to the Beehive community if decisions
about Beehive's future need to be made.
Does anyone have any issues with this? Let me know -- I'm definitely
trying to do the right thing for Beehive here.
Thanks,
Rich
Rich Feit wrote:
>Everyone in our community belongs in this discussion -- thanks for
>joining in. :)
>
>I agree to a point, but I think that some frameworks are similar enough
>that competition among them mainly produces confusion, while truly
>different alternatives (e.g., Ruby on Rails) can move forward with the
>unified support of their communities. I don't really see our
>annotations as competing with XML configuration as much as being a nice
>layer on top of it.
>
>If any notion of competition has motivated me, it's that of competition
>between Java and .NET, not competition with a framework like WebWork
>(whose approach isn't incompatible with ours).
>
>All that said, I think Beehive truly has something different to offer
>(something that's not really present in other frameworks), but it's my
>opinion that it will be stronger if it's combined with its natural allies.
>
>Rich
>
>
>Glauber Reis wrote:
>
>
>
>>I don't know if I belong in this discussion...but isn't the competition
>>between frameworks that brings us so many cool and interesting features?
>>Isn't the difference between them (for instance, some people like Beehive
>>annotations (me inclusive), others like struts config files themselves etc)
>>that make us all happy?
>> --
>>Glauber Adriano
>>
>>On 10/11/05, Rich Feit <ri...@gmail.com> wrote:
>>
>>
>>
>>
>>>No. It means they're reducing scope in order to be able to move
>>>forward. SWF isn't in this either, and the group expressed the hope
>>>that SWF and Beehive will work together in parallel.
>>>
>>>Rich
>>>
>>>Daryl Olander wrote:
>>>
>>>
>>>
>>>
>>>
>>>>So they've rejected Page Flow as the 'C' layer here? Page flow is all
>>>>
>>>>
>>>>
>>>>
>>>about
>>>
>>>
>>>
>>>
>>>>the controller layer. Does this mean that SWF is the exposed controller?
>>>>
>>>>On 10/11/05, Rich Feit <ri...@gmail.com> wrote:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>Thanks for the response, Daryl.
>>>>>
>>>>>I think the Clarity folks realized that they were biting off more than
>>>>>they could chew, so they reduced the scope. Clarity will first focus at
>>>>>the level of Struts/WebWork/Spring MVC, without something like Page
>>>>>Flow. The Beehive community can remain an observer for now (assuming we
>>>>>don't want to try and contribute our tags as their view layer :) ).
>>>>>
>>>>>Rich
>>>>>
>>>>>Daryl Olander wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>Hoping to kick off a bit of a discussion here, I'll start from the
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>stated
>>>
>>>
>>>
>>>
>>>>>>"rules", though these seem to be a bit of both rules and goals....
>>>>>>
>>>>>>I'm not sure that I see a lot of need for consolidation in this market.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>It
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>seems to me like Beehive NetUI has hit a sweet spot. We are already
>>>>>>integrated directly with struts and provide a bunch of V2 Web Framework
>>>>>>support such as meta data, automatic state management, and nesting; too
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>name
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>a few. In addition, we support multiple view technologies and have good
>>>>>>integration with JSF. I've haven't seen Beehive users demand for
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>integration
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>or support of either Spring WebFlow or WebWork. They have asked for
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>AJAX,
>>>
>>>
>>>
>>>
>>>>>>structs migration, etc.
>>>>>>
>>>>>>In addition, I'm not sure what means to consolidate these frameworks.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>Does
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>it mean that the Struts XML configuration file, SWF Flow Definition and
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>an
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>annotated page flow all continue to exist? Or do we take the "ideas"
>>>>>>embodied in these projects (actions, flow, etc) and move them into a
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>new
>>>
>>>
>>>
>>>
>>>>>>light weight framework and simply provide a migration from existing
>>>>>>projects? In today's model for NetUI, we have almost a duel Meta data
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>model
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>at the implementation level (struts config files and annotations in the
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>page
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>flow), but a single programming model (annotations). In a consolidated
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>world
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>are we consolidating at the programming model, configuration and/or API
>>>>>>level?
>>>>>>
>>>>>>There are a number of other frameworks that are stacking out territory
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>in
>>>
>>>
>>>
>>>
>>>>>>this world (JSF/myFaces, Shale, and Seam), should we consider bringing
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>them
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>in? There are bunches of smaller frameworks that certainly have
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>interesting
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>properties (Tapestry) or large number of users (velocity). These aren't
>>>>>>represented here either. Consolidation is an interesting goal, but why
>>>>>>choose some and not others?
>>>>>>
>>>>>>Overall it seems to me, that being at the "top" of the stack, having a
>>>>>>number of choices is good for users. There is less technical reason for
>>>>>>consolidation at this level. You can pick your framework based upon the
>>>>>>features, standards, the programming model, and the tools.
>>>>>>
>>>>>>Second, I'm very uncomfortable about this:
>>>>>>
>>>>>>- *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).*
>>>>>>
>>>>>>I think we cut off adoption of Beehive if we commit to any project that
>>>>>>promises to end-of-life NetUI in the next year or two. Why adopt
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>Beehive
>>>
>>>
>>>
>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>(or
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>SWF) if you know that a year from now, you'll be adopting a new
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>framework? If
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>this is your current choice, I think you'd be better off looking hard
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>at
>>>
>>>
>>>
>>>
>>>>>>Shale and Seam or just continuing to use Struts and see where the dust
>>>>>>settles. Don't we owe our current and future users our ear to listen to
>>>>>>their requirements, criticism and suggestions and implement them to the
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>best
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>of our ability within our framework? Our commitment is to move them
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>forward
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>as the web and technology evolve (AJAX, Web 2.0, EJB 3.0, etc)
>>>>>>
>>>>>>Overall, I feel like Beehive would be better off moving forward. We
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>just
>>>
>>>
>>>
>>>
>>>>>>shipped 1.0 and we have a pile of features we can do, many of which
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>compete
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>directly against Shale, ASP.NET <http://ASP.NET> <http://ASP.NET> <
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>http://ASP.NET>,
>>>
>>>
>>>
>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>RubyOnRails and Seam. If
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>we spent a year developing some of those features we are further along
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>than
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>if we spend a year figuring out how to coexist with a couple of other
>>>>>>existing frameworks.
>>>>>>On 10/10/05, Daryl Olander <do...@gmail.com> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>Pulling from the mail below to summerize (emphasis is mine):
>>>>>>>
>>>>>>>From: Patrick Lightbody <pl...@gmail.com>
>>>>>>>To: Rich Feit <ri...@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.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>>>
>>>>
>>
>>
>>
>>
>
>
>
Re: Beehive/Spring/Struts/WebWork
Posted by Rich Feit <ri...@gmail.com>.
Everyone in our community belongs in this discussion -- thanks for
joining in. :)
I agree to a point, but I think that some frameworks are similar enough
that competition among them mainly produces confusion, while truly
different alternatives (e.g., Ruby on Rails) can move forward with the
unified support of their communities. I don't really see our
annotations as competing with XML configuration as much as being a nice
layer on top of it.
If any notion of competition has motivated me, it's that of competition
between Java and .NET, not competition with a framework like WebWork
(whose approach isn't incompatible with ours).
All that said, I think Beehive truly has something different to offer
(something that's not really present in other frameworks), but it's my
opinion that it will be stronger if it's combined with its natural allies.
Rich
Glauber Reis wrote:
>I don't know if I belong in this discussion...but isn't the competition
>between frameworks that brings us so many cool and interesting features?
>Isn't the difference between them (for instance, some people like Beehive
>annotations (me inclusive), others like struts config files themselves etc)
>that make us all happy?
> --
>Glauber Adriano
>
> On 10/11/05, Rich Feit <ri...@gmail.com> wrote:
>
>
>>No. It means they're reducing scope in order to be able to move
>>forward. SWF isn't in this either, and the group expressed the hope
>>that SWF and Beehive will work together in parallel.
>>
>>Rich
>>
>>Daryl Olander wrote:
>>
>>
>>
>>>So they've rejected Page Flow as the 'C' layer here? Page flow is all
>>>
>>>
>>about
>>
>>
>>>the controller layer. Does this mean that SWF is the exposed controller?
>>>
>>>On 10/11/05, Rich Feit <ri...@gmail.com> wrote:
>>>
>>>
>>>
>>>
>>>>Thanks for the response, Daryl.
>>>>
>>>>I think the Clarity folks realized that they were biting off more than
>>>>they could chew, so they reduced the scope. Clarity will first focus at
>>>>the level of Struts/WebWork/Spring MVC, without something like Page
>>>>Flow. The Beehive community can remain an observer for now (assuming we
>>>>don't want to try and contribute our tags as their view layer :) ).
>>>>
>>>>Rich
>>>>
>>>>Daryl Olander wrote:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>Hoping to kick off a bit of a discussion here, I'll start from the
>>>>>
>>>>>
>>stated
>>
>>
>>>>>"rules", though these seem to be a bit of both rules and goals....
>>>>>
>>>>>I'm not sure that I see a lot of need for consolidation in this market.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>It
>>>>
>>>>
>>>>
>>>>
>>>>>seems to me like Beehive NetUI has hit a sweet spot. We are already
>>>>>integrated directly with struts and provide a bunch of V2 Web Framework
>>>>>support such as meta data, automatic state management, and nesting; too
>>>>>
>>>>>
>>>>>
>>>>>
>>>>name
>>>>
>>>>
>>>>
>>>>
>>>>>a few. In addition, we support multiple view technologies and have good
>>>>>integration with JSF. I've haven't seen Beehive users demand for
>>>>>
>>>>>
>>>>>
>>>>>
>>>>integration
>>>>
>>>>
>>>>
>>>>
>>>>>or support of either Spring WebFlow or WebWork. They have asked for
>>>>>
>>>>>
>>AJAX,
>>
>>
>>>>>structs migration, etc.
>>>>>
>>>>>In addition, I'm not sure what means to consolidate these frameworks.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>Does
>>>>
>>>>
>>>>
>>>>
>>>>>it mean that the Struts XML configuration file, SWF Flow Definition and
>>>>>
>>>>>
>>>>>
>>>>>
>>>>an
>>>>
>>>>
>>>>
>>>>
>>>>>annotated page flow all continue to exist? Or do we take the "ideas"
>>>>>embodied in these projects (actions, flow, etc) and move them into a
>>>>>
>>>>>
>>new
>>
>>
>>>>>light weight framework and simply provide a migration from existing
>>>>>projects? In today's model for NetUI, we have almost a duel Meta data
>>>>>
>>>>>
>>>>>
>>>>>
>>>>model
>>>>
>>>>
>>>>
>>>>
>>>>>at the implementation level (struts config files and annotations in the
>>>>>
>>>>>
>>>>>
>>>>>
>>>>page
>>>>
>>>>
>>>>
>>>>
>>>>>flow), but a single programming model (annotations). In a consolidated
>>>>>
>>>>>
>>>>>
>>>>>
>>>>world
>>>>
>>>>
>>>>
>>>>
>>>>>are we consolidating at the programming model, configuration and/or API
>>>>>level?
>>>>>
>>>>>There are a number of other frameworks that are stacking out territory
>>>>>
>>>>>
>>in
>>
>>
>>>>>this world (JSF/myFaces, Shale, and Seam), should we consider bringing
>>>>>
>>>>>
>>>>>
>>>>>
>>>>them
>>>>
>>>>
>>>>
>>>>
>>>>>in? There are bunches of smaller frameworks that certainly have
>>>>>
>>>>>
>>>>>
>>>>>
>>>>interesting
>>>>
>>>>
>>>>
>>>>
>>>>>properties (Tapestry) or large number of users (velocity). These aren't
>>>>>represented here either. Consolidation is an interesting goal, but why
>>>>>choose some and not others?
>>>>>
>>>>>Overall it seems to me, that being at the "top" of the stack, having a
>>>>>number of choices is good for users. There is less technical reason for
>>>>>consolidation at this level. You can pick your framework based upon the
>>>>>features, standards, the programming model, and the tools.
>>>>>
>>>>>Second, I'm very uncomfortable about this:
>>>>>
>>>>>- *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).*
>>>>>
>>>>>I think we cut off adoption of Beehive if we commit to any project that
>>>>>promises to end-of-life NetUI in the next year or two. Why adopt
>>>>>
>>>>>
>>Beehive
>>
>>
>>>>>
>>>>>
>>>>(or
>>>>
>>>>
>>>>
>>>>
>>>>>SWF) if you know that a year from now, you'll be adopting a new
>>>>>
>>>>>
>>>>>
>>>>>
>>>>framework? If
>>>>
>>>>
>>>>
>>>>
>>>>>this is your current choice, I think you'd be better off looking hard
>>>>>
>>>>>
>>at
>>
>>
>>>>>Shale and Seam or just continuing to use Struts and see where the dust
>>>>>settles. Don't we owe our current and future users our ear to listen to
>>>>>their requirements, criticism and suggestions and implement them to the
>>>>>
>>>>>
>>>>>
>>>>>
>>>>best
>>>>
>>>>
>>>>
>>>>
>>>>>of our ability within our framework? Our commitment is to move them
>>>>>
>>>>>
>>>>>
>>>>>
>>>>forward
>>>>
>>>>
>>>>
>>>>
>>>>>as the web and technology evolve (AJAX, Web 2.0, EJB 3.0, etc)
>>>>>
>>>>>Overall, I feel like Beehive would be better off moving forward. We
>>>>>
>>>>>
>>just
>>
>>
>>>>>shipped 1.0 and we have a pile of features we can do, many of which
>>>>>
>>>>>
>>>>>
>>>>>
>>>>compete
>>>>
>>>>
>>>>
>>>>
>>>>>directly against Shale, ASP.NET <http://ASP.NET> <http://ASP.NET> <
>>>>>
>>>>>
>>http://ASP.NET>,
>>
>>
>>>>>
>>>>>
>>>>RubyOnRails and Seam. If
>>>>
>>>>
>>>>
>>>>
>>>>>we spent a year developing some of those features we are further along
>>>>>
>>>>>
>>>>>
>>>>>
>>>>than
>>>>
>>>>
>>>>
>>>>
>>>>>if we spend a year figuring out how to coexist with a couple of other
>>>>>existing frameworks.
>>>>>On 10/10/05, Daryl Olander <do...@gmail.com> wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>Pulling from the mail below to summerize (emphasis is mine):
>>>>>>
>>>>>>From: Patrick Lightbody <pl...@gmail.com>
>>>>>>To: Rich Feit <ri...@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.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>
>
>
Re: Beehive/Spring/Struts/WebWork
Posted by Glauber Reis <gl...@gmail.com>.
I don't know if I belong in this discussion...but isn't the competition
between frameworks that brings us so many cool and interesting features?
Isn't the difference between them (for instance, some people like Beehive
annotations (me inclusive), others like struts config files themselves etc)
that make us all happy?
--
Glauber Adriano
On 10/11/05, Rich Feit <ri...@gmail.com> wrote:
>
> No. It means they're reducing scope in order to be able to move
> forward. SWF isn't in this either, and the group expressed the hope
> that SWF and Beehive will work together in parallel.
>
> Rich
>
> Daryl Olander wrote:
>
> >So they've rejected Page Flow as the 'C' layer here? Page flow is all
> about
> >the controller layer. Does this mean that SWF is the exposed controller?
> >
> >On 10/11/05, Rich Feit <ri...@gmail.com> wrote:
> >
> >
> >>Thanks for the response, Daryl.
> >>
> >>I think the Clarity folks realized that they were biting off more than
> >>they could chew, so they reduced the scope. Clarity will first focus at
> >>the level of Struts/WebWork/Spring MVC, without something like Page
> >>Flow. The Beehive community can remain an observer for now (assuming we
> >>don't want to try and contribute our tags as their view layer :) ).
> >>
> >>Rich
> >>
> >>Daryl Olander wrote:
> >>
> >>
> >>
> >>>Hoping to kick off a bit of a discussion here, I'll start from the
> stated
> >>>"rules", though these seem to be a bit of both rules and goals....
> >>>
> >>>I'm not sure that I see a lot of need for consolidation in this market.
> >>>
> >>>
> >>It
> >>
> >>
> >>>seems to me like Beehive NetUI has hit a sweet spot. We are already
> >>>integrated directly with struts and provide a bunch of V2 Web Framework
> >>>support such as meta data, automatic state management, and nesting; too
> >>>
> >>>
> >>name
> >>
> >>
> >>>a few. In addition, we support multiple view technologies and have good
> >>>integration with JSF. I've haven't seen Beehive users demand for
> >>>
> >>>
> >>integration
> >>
> >>
> >>>or support of either Spring WebFlow or WebWork. They have asked for
> AJAX,
> >>>structs migration, etc.
> >>>
> >>>In addition, I'm not sure what means to consolidate these frameworks.
> >>>
> >>>
> >>Does
> >>
> >>
> >>>it mean that the Struts XML configuration file, SWF Flow Definition and
> >>>
> >>>
> >>an
> >>
> >>
> >>>annotated page flow all continue to exist? Or do we take the "ideas"
> >>>embodied in these projects (actions, flow, etc) and move them into a
> new
> >>>light weight framework and simply provide a migration from existing
> >>>projects? In today's model for NetUI, we have almost a duel Meta data
> >>>
> >>>
> >>model
> >>
> >>
> >>>at the implementation level (struts config files and annotations in the
> >>>
> >>>
> >>page
> >>
> >>
> >>>flow), but a single programming model (annotations). In a consolidated
> >>>
> >>>
> >>world
> >>
> >>
> >>>are we consolidating at the programming model, configuration and/or API
> >>>level?
> >>>
> >>>There are a number of other frameworks that are stacking out territory
> in
> >>>this world (JSF/myFaces, Shale, and Seam), should we consider bringing
> >>>
> >>>
> >>them
> >>
> >>
> >>>in? There are bunches of smaller frameworks that certainly have
> >>>
> >>>
> >>interesting
> >>
> >>
> >>>properties (Tapestry) or large number of users (velocity). These aren't
> >>>represented here either. Consolidation is an interesting goal, but why
> >>>choose some and not others?
> >>>
> >>>Overall it seems to me, that being at the "top" of the stack, having a
> >>>number of choices is good for users. There is less technical reason for
> >>>consolidation at this level. You can pick your framework based upon the
> >>>features, standards, the programming model, and the tools.
> >>>
> >>>Second, I'm very uncomfortable about this:
> >>>
> >>>- *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).*
> >>>
> >>>I think we cut off adoption of Beehive if we commit to any project that
> >>>promises to end-of-life NetUI in the next year or two. Why adopt
> Beehive
> >>>
> >>>
> >>(or
> >>
> >>
> >>>SWF) if you know that a year from now, you'll be adopting a new
> >>>
> >>>
> >>framework? If
> >>
> >>
> >>>this is your current choice, I think you'd be better off looking hard
> at
> >>>Shale and Seam or just continuing to use Struts and see where the dust
> >>>settles. Don't we owe our current and future users our ear to listen to
> >>>their requirements, criticism and suggestions and implement them to the
> >>>
> >>>
> >>best
> >>
> >>
> >>>of our ability within our framework? Our commitment is to move them
> >>>
> >>>
> >>forward
> >>
> >>
> >>>as the web and technology evolve (AJAX, Web 2.0, EJB 3.0, etc)
> >>>
> >>>Overall, I feel like Beehive would be better off moving forward. We
> just
> >>>shipped 1.0 and we have a pile of features we can do, many of which
> >>>
> >>>
> >>compete
> >>
> >>
> >>>directly against Shale, ASP.NET <http://ASP.NET> <http://ASP.NET> <
> http://ASP.NET>,
> >>>
> >>>
> >>RubyOnRails and Seam. If
> >>
> >>
> >>>we spent a year developing some of those features we are further along
> >>>
> >>>
> >>than
> >>
> >>
> >>>if we spend a year figuring out how to coexist with a couple of other
> >>>existing frameworks.
> >>>On 10/10/05, Daryl Olander <do...@gmail.com> wrote:
> >>>
> >>>
> >>>
> >>>
> >>>>Pulling from the mail below to summerize (emphasis is mine):
> >>>>
> >>>>From: Patrick Lightbody <pl...@gmail.com>
> >>>>To: Rich Feit <ri...@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.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >
> >
> >
>
Re: Beehive/Spring/Struts/WebWork
Posted by Rich Feit <ri...@gmail.com>.
No. It means they're reducing scope in order to be able to move
forward. SWF isn't in this either, and the group expressed the hope
that SWF and Beehive will work together in parallel.
Rich
Daryl Olander wrote:
>So they've rejected Page Flow as the 'C' layer here? Page flow is all about
>the controller layer. Does this mean that SWF is the exposed controller?
>
>On 10/11/05, Rich Feit <ri...@gmail.com> wrote:
>
>
>>Thanks for the response, Daryl.
>>
>>I think the Clarity folks realized that they were biting off more than
>>they could chew, so they reduced the scope. Clarity will first focus at
>>the level of Struts/WebWork/Spring MVC, without something like Page
>>Flow. The Beehive community can remain an observer for now (assuming we
>>don't want to try and contribute our tags as their view layer :) ).
>>
>>Rich
>>
>>Daryl Olander wrote:
>>
>>
>>
>>>Hoping to kick off a bit of a discussion here, I'll start from the stated
>>>"rules", though these seem to be a bit of both rules and goals....
>>>
>>>I'm not sure that I see a lot of need for consolidation in this market.
>>>
>>>
>>It
>>
>>
>>>seems to me like Beehive NetUI has hit a sweet spot. We are already
>>>integrated directly with struts and provide a bunch of V2 Web Framework
>>>support such as meta data, automatic state management, and nesting; too
>>>
>>>
>>name
>>
>>
>>>a few. In addition, we support multiple view technologies and have good
>>>integration with JSF. I've haven't seen Beehive users demand for
>>>
>>>
>>integration
>>
>>
>>>or support of either Spring WebFlow or WebWork. They have asked for AJAX,
>>>structs migration, etc.
>>>
>>>In addition, I'm not sure what means to consolidate these frameworks.
>>>
>>>
>>Does
>>
>>
>>>it mean that the Struts XML configuration file, SWF Flow Definition and
>>>
>>>
>>an
>>
>>
>>>annotated page flow all continue to exist? Or do we take the "ideas"
>>>embodied in these projects (actions, flow, etc) and move them into a new
>>>light weight framework and simply provide a migration from existing
>>>projects? In today's model for NetUI, we have almost a duel Meta data
>>>
>>>
>>model
>>
>>
>>>at the implementation level (struts config files and annotations in the
>>>
>>>
>>page
>>
>>
>>>flow), but a single programming model (annotations). In a consolidated
>>>
>>>
>>world
>>
>>
>>>are we consolidating at the programming model, configuration and/or API
>>>level?
>>>
>>>There are a number of other frameworks that are stacking out territory in
>>>this world (JSF/myFaces, Shale, and Seam), should we consider bringing
>>>
>>>
>>them
>>
>>
>>>in? There are bunches of smaller frameworks that certainly have
>>>
>>>
>>interesting
>>
>>
>>>properties (Tapestry) or large number of users (velocity). These aren't
>>>represented here either. Consolidation is an interesting goal, but why
>>>choose some and not others?
>>>
>>>Overall it seems to me, that being at the "top" of the stack, having a
>>>number of choices is good for users. There is less technical reason for
>>>consolidation at this level. You can pick your framework based upon the
>>>features, standards, the programming model, and the tools.
>>>
>>>Second, I'm very uncomfortable about this:
>>>
>>>- *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).*
>>>
>>>I think we cut off adoption of Beehive if we commit to any project that
>>>promises to end-of-life NetUI in the next year or two. Why adopt Beehive
>>>
>>>
>>(or
>>
>>
>>>SWF) if you know that a year from now, you'll be adopting a new
>>>
>>>
>>framework? If
>>
>>
>>>this is your current choice, I think you'd be better off looking hard at
>>>Shale and Seam or just continuing to use Struts and see where the dust
>>>settles. Don't we owe our current and future users our ear to listen to
>>>their requirements, criticism and suggestions and implement them to the
>>>
>>>
>>best
>>
>>
>>>of our ability within our framework? Our commitment is to move them
>>>
>>>
>>forward
>>
>>
>>>as the web and technology evolve (AJAX, Web 2.0, EJB 3.0, etc)
>>>
>>>Overall, I feel like Beehive would be better off moving forward. We just
>>>shipped 1.0 and we have a pile of features we can do, many of which
>>>
>>>
>>compete
>>
>>
>>>directly against Shale, ASP.NET <http://ASP.NET> <http://ASP.NET>,
>>>
>>>
>>RubyOnRails and Seam. If
>>
>>
>>>we spent a year developing some of those features we are further along
>>>
>>>
>>than
>>
>>
>>>if we spend a year figuring out how to coexist with a couple of other
>>>existing frameworks.
>>>On 10/10/05, Daryl Olander <do...@gmail.com> wrote:
>>>
>>>
>>>
>>>
>>>>Pulling from the mail below to summerize (emphasis is mine):
>>>>
>>>>From: Patrick Lightbody <pl...@gmail.com>
>>>>To: Rich Feit <ri...@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.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>
>
>
Re: Beehive/Spring/Struts/WebWork
Posted by Daryl Olander <do...@gmail.com>.
So they've rejected Page Flow as the 'C' layer here? Page flow is all about
the controller layer. Does this mean that SWF is the exposed controller?
On 10/11/05, Rich Feit <ri...@gmail.com> wrote:
>
> Thanks for the response, Daryl.
>
> I think the Clarity folks realized that they were biting off more than
> they could chew, so they reduced the scope. Clarity will first focus at
> the level of Struts/WebWork/Spring MVC, without something like Page
> Flow. The Beehive community can remain an observer for now (assuming we
> don't want to try and contribute our tags as their view layer :) ).
>
> Rich
>
> Daryl Olander wrote:
>
> >Hoping to kick off a bit of a discussion here, I'll start from the stated
> >"rules", though these seem to be a bit of both rules and goals....
> >
> >I'm not sure that I see a lot of need for consolidation in this market.
> It
> >seems to me like Beehive NetUI has hit a sweet spot. We are already
> >integrated directly with struts and provide a bunch of V2 Web Framework
> >support such as meta data, automatic state management, and nesting; too
> name
> >a few. In addition, we support multiple view technologies and have good
> >integration with JSF. I've haven't seen Beehive users demand for
> integration
> >or support of either Spring WebFlow or WebWork. They have asked for AJAX,
> >structs migration, etc.
> >
> >In addition, I'm not sure what means to consolidate these frameworks.
> Does
> >it mean that the Struts XML configuration file, SWF Flow Definition and
> an
> >annotated page flow all continue to exist? Or do we take the "ideas"
> >embodied in these projects (actions, flow, etc) and move them into a new
> >light weight framework and simply provide a migration from existing
> >projects? In today's model for NetUI, we have almost a duel Meta data
> model
> >at the implementation level (struts config files and annotations in the
> page
> >flow), but a single programming model (annotations). In a consolidated
> world
> >are we consolidating at the programming model, configuration and/or API
> >level?
> >
> >There are a number of other frameworks that are stacking out territory in
> >this world (JSF/myFaces, Shale, and Seam), should we consider bringing
> them
> >in? There are bunches of smaller frameworks that certainly have
> interesting
> >properties (Tapestry) or large number of users (velocity). These aren't
> >represented here either. Consolidation is an interesting goal, but why
> >choose some and not others?
> >
> >Overall it seems to me, that being at the "top" of the stack, having a
> >number of choices is good for users. There is less technical reason for
> >consolidation at this level. You can pick your framework based upon the
> >features, standards, the programming model, and the tools.
> >
> >Second, I'm very uncomfortable about this:
> >
> >- *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).*
> >
> >I think we cut off adoption of Beehive if we commit to any project that
> >promises to end-of-life NetUI in the next year or two. Why adopt Beehive
> (or
> >SWF) if you know that a year from now, you'll be adopting a new
> framework? If
> >this is your current choice, I think you'd be better off looking hard at
> >Shale and Seam or just continuing to use Struts and see where the dust
> >settles. Don't we owe our current and future users our ear to listen to
> >their requirements, criticism and suggestions and implement them to the
> best
> >of our ability within our framework? Our commitment is to move them
> forward
> >as the web and technology evolve (AJAX, Web 2.0, EJB 3.0, etc)
> >
> >Overall, I feel like Beehive would be better off moving forward. We just
> >shipped 1.0 and we have a pile of features we can do, many of which
> compete
> >directly against Shale, ASP.NET <http://ASP.NET> <http://ASP.NET>,
> RubyOnRails and Seam. If
> >we spent a year developing some of those features we are further along
> than
> >if we spend a year figuring out how to coexist with a couple of other
> >existing frameworks.
> >On 10/10/05, Daryl Olander <do...@gmail.com> wrote:
> >
> >
> >>Pulling from the mail below to summerize (emphasis is mine):
> >>
> >>From: Patrick Lightbody <pl...@gmail.com>
> >>To: Rich Feit <ri...@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.
> >>
> >>
> >>
> >>
> >>
> >
> >
> >
>
Re: Beehive/Spring/Struts/WebWork
Posted by Rich Feit <ri...@gmail.com>.
Thanks for the response, Daryl.
I think the Clarity folks realized that they were biting off more than
they could chew, so they reduced the scope. Clarity will first focus at
the level of Struts/WebWork/Spring MVC, without something like Page
Flow. The Beehive community can remain an observer for now (assuming we
don't want to try and contribute our tags as their view layer :) ).
Rich
Daryl Olander wrote:
>Hoping to kick off a bit of a discussion here, I'll start from the stated
>"rules", though these seem to be a bit of both rules and goals....
>
>I'm not sure that I see a lot of need for consolidation in this market. It
>seems to me like Beehive NetUI has hit a sweet spot. We are already
>integrated directly with struts and provide a bunch of V2 Web Framework
>support such as meta data, automatic state management, and nesting; too name
>a few. In addition, we support multiple view technologies and have good
>integration with JSF. I've haven't seen Beehive users demand for integration
>or support of either Spring WebFlow or WebWork. They have asked for AJAX,
>structs migration, etc.
>
>In addition, I'm not sure what means to consolidate these frameworks. Does
>it mean that the Struts XML configuration file, SWF Flow Definition and an
>annotated page flow all continue to exist? Or do we take the "ideas"
>embodied in these projects (actions, flow, etc) and move them into a new
>light weight framework and simply provide a migration from existing
>projects? In today's model for NetUI, we have almost a duel Meta data model
>at the implementation level (struts config files and annotations in the page
>flow), but a single programming model (annotations). In a consolidated world
>are we consolidating at the programming model, configuration and/or API
>level?
>
>There are a number of other frameworks that are stacking out territory in
>this world (JSF/myFaces, Shale, and Seam), should we consider bringing them
>in? There are bunches of smaller frameworks that certainly have interesting
>properties (Tapestry) or large number of users (velocity). These aren't
>represented here either. Consolidation is an interesting goal, but why
>choose some and not others?
>
>Overall it seems to me, that being at the "top" of the stack, having a
>number of choices is good for users. There is less technical reason for
>consolidation at this level. You can pick your framework based upon the
>features, standards, the programming model, and the tools.
>
>Second, I'm very uncomfortable about this:
>
>- *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).*
>
>I think we cut off adoption of Beehive if we commit to any project that
>promises to end-of-life NetUI in the next year or two. Why adopt Beehive (or
>SWF) if you know that a year from now, you'll be adopting a new framework? If
>this is your current choice, I think you'd be better off looking hard at
>Shale and Seam or just continuing to use Struts and see where the dust
>settles. Don't we owe our current and future users our ear to listen to
>their requirements, criticism and suggestions and implement them to the best
>of our ability within our framework? Our commitment is to move them forward
>as the web and technology evolve (AJAX, Web 2.0, EJB 3.0, etc)
>
>Overall, I feel like Beehive would be better off moving forward. We just
>shipped 1.0 and we have a pile of features we can do, many of which compete
>directly against Shale, ASP.NET <http://ASP.NET>, RubyOnRails and Seam. If
>we spent a year developing some of those features we are further along than
>if we spend a year figuring out how to coexist with a couple of other
>existing frameworks.
>On 10/10/05, Daryl Olander <do...@gmail.com> wrote:
>
>
>>Pulling from the mail below to summerize (emphasis is mine):
>>
>>From: Patrick Lightbody <pl...@gmail.com>
>>To: Rich Feit <ri...@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.
>>
>>
>>
>>
>>
>
>
>
Re: Beehive/Spring/Struts/WebWork
Posted by Daryl Olander <do...@gmail.com>.
Hoping to kick off a bit of a discussion here, I'll start from the stated
"rules", though these seem to be a bit of both rules and goals....
I'm not sure that I see a lot of need for consolidation in this market. It
seems to me like Beehive NetUI has hit a sweet spot. We are already
integrated directly with struts and provide a bunch of V2 Web Framework
support such as meta data, automatic state management, and nesting; too name
a few. In addition, we support multiple view technologies and have good
integration with JSF. I've haven't seen Beehive users demand for integration
or support of either Spring WebFlow or WebWork. They have asked for AJAX,
structs migration, etc.
In addition, I'm not sure what means to consolidate these frameworks. Does
it mean that the Struts XML configuration file, SWF Flow Definition and an
annotated page flow all continue to exist? Or do we take the "ideas"
embodied in these projects (actions, flow, etc) and move them into a new
light weight framework and simply provide a migration from existing
projects? In today's model for NetUI, we have almost a duel Meta data model
at the implementation level (struts config files and annotations in the page
flow), but a single programming model (annotations). In a consolidated world
are we consolidating at the programming model, configuration and/or API
level?
There are a number of other frameworks that are stacking out territory in
this world (JSF/myFaces, Shale, and Seam), should we consider bringing them
in? There are bunches of smaller frameworks that certainly have interesting
properties (Tapestry) or large number of users (velocity). These aren't
represented here either. Consolidation is an interesting goal, but why
choose some and not others?
Overall it seems to me, that being at the "top" of the stack, having a
number of choices is good for users. There is less technical reason for
consolidation at this level. You can pick your framework based upon the
features, standards, the programming model, and the tools.
Second, I'm very uncomfortable about this:
- *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).*
I think we cut off adoption of Beehive if we commit to any project that
promises to end-of-life NetUI in the next year or two. Why adopt Beehive (or
SWF) if you know that a year from now, you'll be adopting a new framework? If
this is your current choice, I think you'd be better off looking hard at
Shale and Seam or just continuing to use Struts and see where the dust
settles. Don't we owe our current and future users our ear to listen to
their requirements, criticism and suggestions and implement them to the best
of our ability within our framework? Our commitment is to move them forward
as the web and technology evolve (AJAX, Web 2.0, EJB 3.0, etc)
Overall, I feel like Beehive would be better off moving forward. We just
shipped 1.0 and we have a pile of features we can do, many of which compete
directly against Shale, ASP.NET <http://ASP.NET>, RubyOnRails and Seam. If
we spent a year developing some of those features we are further along than
if we spend a year figuring out how to coexist with a couple of other
existing frameworks.
On 10/10/05, Daryl Olander <do...@gmail.com> wrote:
>
> Pulling from the mail below to summerize (emphasis is mine):
>
> From: Patrick Lightbody <pl...@gmail.com>
> To: Rich Feit <ri...@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.
>
>
>
Re: Beehive/Spring/Struts/WebWork
Posted by Daryl Olander <do...@gmail.com>.
Pulling from the mail below to summerize (emphasis is mine):
From: Patrick Lightbody <pl...@gmail.com>
To: Rich Feit <ri...@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 <ri...@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 <pl...@gmail.com>
> To: Rich Feit <ri...@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" <ke...@interface21.com>
> To: "Rich Feit" <ri...@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
>
>
>
>