struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ted Husted" <>
Subject Re: [action2] Public API first draft
Date Fri, 05 May 2006 11:56:45 GMT
+1 for what Don is saying.

I've been heads-down updating the new wiki, so that when the code is
ready, the documentation will be too. The material on the wiki is
generally excellent, but there are "rough spots" there too, that I've
been trying to smooth over. Accordingly, I haven't been following the
API discussions closely yet, since I expect there will be more forward
momentum on this after JavaOne. I won't be at JavaOne myself, but I'm
certain Don, Patrick, Jason, Bob and others will have much to report
when it's over :)

In the meantime, I'll keep working on all the other things we need to
do to make SAF 2 success, including even more example applications in
which to test these brave new API changes :)


On 5/4/06, Don Brown <> wrote:
> I'm not quite ready for a vote on the API, because I think what we'd be voting
> on is still under active discussion.
> We could decide under what criteria we will be evaluating these API changes.  I
> propose they be:
>   1. Can we get a GA release out by August?
>   2. Will at least WebWork 2 apps have an easy (as in hours, not days) transition?
> I realize that might mean we have to put of some more drastic changes to the
> next release, and it may result in some compromises, but in the end, I think it
> is more important to get a usable, timely release out to our users, and ensure
> their migration will be smooth.  Migration, in particular, is a key concern
> because it is an important advantage we could hold, as other frameworks tend to
> require a complete redesign and re-education of developers.  I want Struts
> Action Framework 2 to be seen as easy and powerful, not just from a feature
> standpoint, but also migration, education, and "conceptual space" one.
> This doesn't preclude making sweeping API changes that the average users either
> won't see or aren't noticed since the old objects/interfaces still work
> correctly.  The question then becomes one of energy available to offset new
> changes with proper backwards-compatibility support.
> Struts users have been looking for a smooth transition to next-generation
> technologies for some time now, and I think we've let them down.  It is time to
> deliver.
> Don

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message