Pete, Good review. I was equally impressed with the talk. Most impressive was the annotation-based Spring MVC. I'm trying to get my head around that right now. One thing, I'm pretty sure Keith was using the Spring IDE throughout the entire talk. You might ping him on it. Erik

Pete, I thoroughly enjoyed speaking to the group Wednesday night. Thanks for this story covering the evening! Just a few comments: - I was using the SpringSource Tools Suite, which builds on Eclipse 3.3, Spring IDE 2.0.5, and Eclipse Mylyn, throughout the demo session. You're right, I didn't focus on the specific IDE features in the demo, as we were more focused on going through the latest Spring Web features (and of course the code!) The tooling, though, particularly around the management of Spring configuration, is essential! - Regarding Web Flow and debugging: Yes, today there is no flow debugger like there is a Java debugger. However, you can most certainly debug flows quickly and in a repeatable manner by writing flow unit tests, and that is what we recommend there (automated testing is a best practice in general, of course!). I do eventually expect we will have the tooling capability to step through a flow execution in real time like you can do the execution of Java code. - Regarding the roadmap: yes, we are exploring *broadening* today's flow definition language into the concept of a "site definition language", where a site can consist of many elements, where some elements can be bookmarkable pages, others can be controlled flows, others REST endpoints, etc -- all definable at the same level of abstraction in a declarative manner. Yes, we are looking at incorporating Groovy there to allow the use of script for handling user events and other user actions in a dynamic manner. This work is just getting going, and we'll be making the first of it available to the community soon for feedback. Also, we will have full support for the Web Flow 2 flow definition format in this "site definition" world for defining reusable flows! - Regarding "Spring being wrapped by others": The Spring Framework and its portfolio projects are and will always be Apache-licensed, which means they are licensed in a manner that allows and encourages them to be integrated, built on, and extended. And we like that! In that way, our work can help bring solution providers of all types competitive advantage. And it is good for us because it drives adoption of Spring and growth of the Spring community. The newly announced SpringSource Application Platform is licensed under a different license, the GPLv3, because it is a different kind of product--a next generation server platform. We wouldn't want Oracle or IBM to be able to build on our server platform to offer their own competing, closed source product, for example, hence why that license is different. Trust me, I won't get mad if someone embeds Spring Web Flow and uses it in an unique way to bring value to their customers... its designed for that, and that's why it and the other Spring projects are and will continue to be Apache licensed.

Just a few additional remarks about JavaServerFaces: We ran out of time in the presentation, of course, so I was unable to show Spring Faces in detail. But I do want to clarify a couple of points: - As i mentioned in the talk, I believe JSF, as it and most of the JSF component libraries exist today, is not a fit for all types of web applications. If you're developing a "RESTful" web application that exposes your application's functionality as a set of independently addressable resources, JSF is not a fit. This is primarily because the JSF UI model is stateful, while a REST architecture is stateless Now, it *is* possible for JSF to be used in a stateless manner, but this is not the typical usage today. - JSF is a good fit for web applications that should look and feel like a desktop application. We believe the main problem with JSF in the past and any perception of it as a "poorly regarded" web framework is not the fault of the framework itself, but how the framework is traditionally used in practice. So what we have done with Spring Faces is provide first-class support for making JSF development work in practice in a Spring environment. The core of this support allows you to use the JSF UI component model as a View technology inside Spring MVC and Web Flow. So you can adopt the "bread-n-butter" of JSF -- the componet model and the available component libraries -- while keeping the rest of your architecture intact. I hope this clarifies a few things related to JSF given the limited time we had to spend on the topic! If you are developing a rich web application with a desktop-like L&F, JSF is not a bad choice, and Spring Faces can make you a lot more productive. It should be viewed as just another tool in the Spring developers toolbox to be used when it makes sense for the problem at hand.

Gotta agree Erik, the Spring group is really kicking some butt. You always have good talks but this one was smoking !

I had to put at least something about IDEs in there, I guess my comment was pretty lame :)