Consolidation is a relatively unknown concept in the crowded web
framework space. While most frameworks are open source allowing
cross-pollination, collaboration is still rare resulting in duplicated
efforts and confusion for the end user. Struts Ti, a next-gen project
in the Struts sandbox, tried to buck the trend by building on WebWork
rather than wasting its time writing yet another Model2 framework.
Taking this level of cooperation to the next level, developers from four
popular web frameworks - Struts, Spring, WebWork, and Beehive, have
gotten together to discuss the possibility of consolidating their
efforts into a new project, termed Clarity. Clarity would be an
action-based MVC framework that combines the commonality of the four
aforementioned frameworks into one that can be built upon by all.
These discussions have just began, and while no one has "officially"
signed on, I thought I should bring it before the Struts community for
feedback. There is still much to work out, but I want to keep the
community involved from the beginning.
I personally am excited about this project and think it will be
beneficial to users and developers alike. The Struts Classic code base
is showing its age, but speaking as a developer who maintains old Struts
apps, few people have the time and budget to rewrite them from scratch
with a more disparate framework like Shale or Wicket. I think Clarity
would be a much easier migration for existing Struts applications and
developers, yet support key standards like Portlets and JSF.
Attached is two messages in a private email thread between Patrick
Lightbody (WebWork), Keith Donald (Spring), Rich Feit (Beehive), and me,
that started the Clarity discussion. We plan to have a public email
list for Clarity discussion, but it hasn't been setup yet.
What I'm looking for from the Struts community is if you think this is a
good idea, and if you do, what we need to do to make it work.
Personally, I don't expect Struts or even Struts Classic going away at
all even if we agreed Clarity is migration path, so this isn't an
either/or discussion.
Again, this is _NOT_ a project announcement meant for the world, only
the beginning of a discussion about the idea of consolidating a few web
frameworks and how Struts fits in with this. Looking forward to the
comments,
Don
=== Initial kickoff by Patrick Lightbody from WebWork ===
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.
>
> 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.
>
> 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...
>
> 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.
>
> 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
=== Keith Donald from Spring Web Flow/MVC ===
Keith Donald wrote:
> I think a good first step is to clearly state what we all expect to
gain out
> of working together, given the dynamics of this market, and what our
> individual expectations are:
>
> Here's my take:
> --------------
> If you look at the open source web framework market, I see these camps:
>
> 1. Action-centric (Struts Classic, Struts Ti, Spring MVC, WW, SWF,
Beehive)
> 2. Component-centric (JSF-based <Struts Shale, JBoss Seam>, Tapestry,
> Wicket, Echo)
> 3. Ruby on Rails
>
> Options in camps #2 and #3 represent considerable more shock to adopt
than
> those in #1. This is for various reasons, but mainly because the
majority
> of the market (existing Struts users) can more naturally migrate to the
> other action-centric frameworks. Spring MVC, for example, has been
> positioned as a more extensible Struts and that strategy has proven
fairly
> effective. Spring Web Flow, is usable as a component from within both
> Struts classic and Spring MVC, and that too has proven effective.
Beehive
> is built on Struts.
>
> So there is definite overlap (and some compliment, too) between Struts,
> Spring MVC, WW, SWF, and Beehive, and I think it's fair to say we share
> similar goals for tackling the same problems. Because of this, there
is a
> natural fit for consolidation/collaboration, motivated more now by two
> external forces:
>
> 1. Camps #2 and #3 are threats. RoR is one, JBoss Seam is another.
>
> 2. The market is fragmented, and that creates user confusion. There
is no
> clear "next paradigm" <is JSF the base for that or not?>, and that
creates
> (encourages?) opportunity for new entrants with little invested thus
far to
> jump in and steal the show (look what Seam is trying to do, and the
RoR hype
> coming from high-profile independents in the Java community).
>
> --
>
> So the "clarity" project in my mind should be about providing a clear
"next"
> choice in the web-space for the Struts Classic, TI, WW, Beehive, and
Spring
> communities, with the premise being we'd be a lot stronger together
than we
> would competing with one another in essentially similar (but slightly
> different) ways.
>
> From my perspective, I think it's important to market a full-stack
product,
> "clarity", which unites our respective brands/technologies; however,
I feel
> it's just as important that such a stack be built from a set of
> best-of-breed components that lends itself to choice. For example, we
> wouldn't want to just ignore JSF, it's not going away (and that is
exactly
> why Spring has made JSF integration a high priority, integrating SWF as a
> more powerful JSF NavigationHandler).
>
> The ultimate goal, though, would be to win on the full-stack, the
"clarity"
> brand, appealing to a message of simplicity comparable to RoR but without
> the shock.
>
> Interface21 would be willing to fund marketing and technical effort
behind
> this (including hosting infrastructure), hopefully with the support
of BEA
> as well.
>
> --
>
> From Spring's perspective there are a couple of expectations/issues I
want
> to get out there:
>
> - Spring in general has moved from being the gem of the technology
> enthusiasts to more of a rock for the pragmatists (early majority).
This is
> more of the case for Spring's middle ware stack (IoC/TX/DAO/etc), but
Spring
> MVC also applies to some degree as it is shipped with the core framework.
> Among other things, this means Interface21 and BEA are now in the
business
> of providing Spring support/training/certification, and that entails
> contractual obligations for supporting existing versions of Spring.
So work
> on any part of the framework just can't stop on a dime: we must
continue to
> support our customers. Backwards compatibility, as well as the
ability to
> run on existing infrastructure <JDK 1.3 or >), is very important to
us for
> this reason.
>
> With that said, however, we do expect more support work around Spring's
> middle ware stack, as it is more widely used than Spring MVC. So we
do have
> more flexibility for change with Spring MVC, but we just can't stop
> supporting it. Likewise, we'd want a "clarity" migration from Spring
MVC to
> be as easy as possible.
>
> I think ease of adoption is important to all of us, else our own
communities
> may turn on us.
>
> - Spring Web Flow represents a major investment for us in the last year.
> We've put much more resources into SWF than we have MVC, as MVC has
always
> been a foundation to build on while SWF is a full-featured page flow
> product. SWF is also at a different place in the market than MVC: as
a new
> product positioned as a breakthrough technology, it is the gem of the
> enthusiast at this point. We expect when it reaches 1.0 it will become
> widely adopted quickly, as it has considerable momentum now, and is well
> positioned.
>
> Given that, I see opportunity with Clarity to capitalize on synergy
between
> SWF and Beehive PF and also leverage the momentum of SWF's
approaching 1.0
> release. I do have concerns of dilution: we wouldn't want to dilute the
> effort/branding we've put into SWF, and risk losing the momentum we
have now
> (or worse, giving it away to say JBoss Seam, who is trying to play
catchup
> with both of us).
>
> What I'm saying is SWF is going to be successful on its own, as a new
> product addressing an untapped niche, so we want to make sure we take
> advantage of that with Clarity without dilution... and do so quickly,
before
> other competitors have a chance to stake a claim by copying it and making
> the clone a part of their "full stack".
>
> --
>
> I hope this provides some insight into where Spring is coming from
and our
> interest with Clarity. I feel this is unique opportunity to come
together
> and leverage the best in each of our respective products, and unite our
> communities under a common brand whose development is sustained not
only by
> open source developers but commercial companies such as Interface21
and BEA
> as well.
>
> Once we have it out in the open what we all hope to gain, I think a good
> next step is to start flushing out from a technical perspective what this
> thing would look like--in the ideal, and keeping in mind migration
from our
> existing products, and the need for components at each key part in the
> stack. Once the technical architecture is understood, then I think it's
> natural to start focusing on marketing/branding.
>
> Keith
>
> -----Original Message-----
> From: Patrick Lightbody [mailto:[EMAIL PROTECTED]
> Sent: Thursday, October 06, 2005 11:20 AM
> To: Rich Feit
> Cc: Keith Donald; Don Brown; Jason Carreira
> 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
>>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
