beehive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John Kaplan" <jkap...@bea.com>
Subject RE: Beehive/Spring/Struts/WebWork
Date Fri, 14 Oct 2005 16:33:01 GMT
I agree, Rich.

The discussion is healthy and can only be good for Beehive, regardless
of the outcome.

Thanks,
- John

-----Original Message-----
From: Rich Feit [mailto:richfeit@gmail.com] 
Sent: Friday, October 14, 2005 9:30 AM
To: dev@beehive.apache.org
Subject: Re: Beehive/Spring/Struts/WebWork

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 <richfeit@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 <richfeit@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 <dolander@gmail.com> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>         
>>>>>>
>>>>>>            
>>>>>>
>>>>>>>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.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>           
>>>>>>>
>>>>>>>              
>>>>>>>
>>>>>>         
>>>>>>
>>>>>>            
>>>>>>
>>>>     
>>>>
>>>>        
>>>>
>> 
>>
>>    
>>
>
>  
>


Mime
View raw message