I tried to make this post shorter, but this is the best I could do :( Patrick Lightbody wrote: > Above all else, we recognize that consolidation is the overriding goal.
IMHO, for a consolidation project to succeed beyond the scope of enthusiasts, a migration path has to be a primary objective. Will projects like JIRA and Confluence be able to migrate from WebWork to Clarity, without starting over? Will Oracle and WebSphere be able to migrate their tools from Struts to Clarity, without starting over? Ditto for Landsend and Citibank and hundreds (or thousands) of other non-trivial applications? If our goal is to consolidate not only the development base but the user base, then we must be sure that significant, non-trivial applications can "get there from here". The importance of a migration path cannot be understated. I would suggest that migration be part of the mission statement. Of course, Clarity should not be shackled by the tyranny of the installed base (as is Struts Classic). We should not have to make too many compromises for the sake of backward compatability. Somehow, a balance must be struck. Patrick Lightbody wrote: > 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). One way to view a migration path is converting an application in a fell swoop. Another way to view a migration path is evolving an application, step by step. If we know that Clarity is the end, prexisting projects can march applications toward that end, using a proven deprecate/release/remove cycle. Rather than view existing projects as "legacies" to be discarded, perhaps we could view them as "stepping stones" that will lead us all to Clarity, feature by feature. We should recognize that getting projects from "here to there" is not something that will take months. Realistically, migration is a process that will take several years for most people. We should recognize that reality and plan for it. We must recognize that teams are not going to jump ship just because we jump first. (Witness JSF.) Rather than desert proven solutions, we must be ready to set a course and steer each ship to a common port. It will take time, but we have time -- if we don't try to rush people. Internet time is dead. Most teams are living in enterprise time now, with product cycles that span several years, not a handful of months. After investing several years of development into Struts or WebWork or Spring MVC, prudent product managers are not going to choose something else without a clear migration path. Sun itself has been trying to do just that. How can any other group hope to succeed where Sun is not, unless we take the time to build gentle ramps to our unified platform? Patrick Lightbody wrote: > This place must be detached from Jakarta/Struts, Spring, and OpenSymphony > and must stay that way until we all feel comfortable working together. To complete the initial planning, neutral ground sounds like a good idea. If there's interest, we could setup an independant Confluence space for Clarity that can be as public or private as we like. The space provided by Atlassian and is not affiliated with the ASF. * http://opensource2.atlassian.com/confluence/oss/ You know, the OO modeling community faced a similar problem ten years ago. As Martin Fowler puts it in "UML Distilled" : "The same basic concepts would appear in very different notations, which caused confusion" ... "Talk of standardization had surfaced, but nobody seemed willing to do anything about it". There were some independant attempts at standardization, which failed. Then, the marketplace leaders -- the "three amigos:" Brooch, Jacobson, and Rumbaugh -- got together and defined UML, which went on to become an OMG standard (in not-so-painless process). It seems like the same thing is starting to happen again, except here we have the four musketeers -- Beehive, Spring, Struts, and WebWork -- riding out to save the day :) Personally, I would suggest that Clarity not stay an "independant" project too long. No matter what we say about "legacy" projects and "clear choices", as an independant project Clarity *will* be viewed as a third alternative to Struts Classic or JSF. This is an inevitable marketplace dynamic, and there is nothing anyone can do to avoid it. When the time comes, Clarity should seriously consider whether it would like to be a Struts product. By adopting Shale and considering TI, Struts has shown that we consider the project to be more than the direct descendant of Craig's Action package. As a Struts product, Clarity would have immediate access to thousands of teams that have already obtained approval to use Struts. As an independant, many teams will have to wait months or even years to get Clarity on the approved software list. Getting on the short list is a painful process in many enteprises, and a key reason why more teams are not already using Spring. (Gotta love Spring!) If it is the users and the marketplace that Clarity cares about, then the best thing for the marketplace would be to leverage the very strong brand that Struts already offers. The Struts brand is arguably as strong, or stronger, than all the other brands combined. If we circle the wagons around Apache Struts, we will have the opportunity to not only build something better than Struts, WebWork, or Spring MVC ever could be, but we will have a ready-made distribution channel waiting for us when we are done. By playing to our strengths, it will be much easier for users to perceive Clarity as *the* unified, single-source alternative to .NET or PHP or Ruby. Once upon a time, we talked about making Stuts 2.x a "best of breeds" framework. We talked about adopting and adapting the best ideas from the other frameworks and creating a brave, new framework that better met all of our needs. Putting all the marketplace mumbo-jumbo aside, I think that's what Clarity wants too. There will probably never be a Struts Classic 2.x, but, if we are willing, there could be a Struts Clarity 1.x. Patrick Lightbody wrote: > 4) Now for the hard part: map out a technical implementation. The first three technical questions I'd be asking about Clarity are (1) What services should a web application framework provide? What are our Use Cases? * http://opensource2.atlassian.com/confluence/oss/display/STRUTS/Use+Cases (2) Which of these Use Cases are being solved by existing frameworks? For each of these cases, is one of the existing solutions clearly more effective than the alternatives? (3) Which of these Use Cases are not being solved, or solved well, by existing frameworks? -- HTH, Ted. http://www.husted.com/poe/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
