… or day 2, by the official count. Today was the first full day of sessions, though, so I’m counting from 1.
From now on, I can only comment on the sessions I attended. There were many parallel sessions I wish I could have gone to, but until I get one of those cool Time Turner like Hermione Granger had in the third Harry Potter movie, I still have to operate synchronously. I’ll just make some comments about each here.
Since the conference is a combined one, I decided I should try to attend some Spring sessions as well as Groovy/Grails/Griffon ones. The first session I went to was “Overview of the Spring 3.0 Web Stack,” given by Keith Donald. This was a major overview, with some discussion of Spring MVC, Spring JavaScript, Spring Web Flow, Spring Faces, Spring Security, and even Spring BlazeDS Integration. That’s obviously way more that can be covered in one session, so a lot of the slides were really pointers to other presentations given later in the conference.
That said, after the introductory material he spent a fair amount of time on the new REST support in Spring MVC 3.0. I’ve been working with Spring 2.5 for some time, and I’ve played with the new MVC annotations like @Controller and @Service, but I hadn’t seen the RESTful ones yet.
To give us an idea what’s coming, Keith went over parts of the new sample application for Spring MVC 3.0, yet another version of their PetClinic app. For those interested in looking at it, the svn repository for the RESTful PetClinic is here. Feel free to check it out.
Keith spent a fair amount of time on ways to do the URL mapping, the new validator framework, and the new formatters that replace custom property editors. This isn’t the right post for a detailed discussion, so I’ll refer you to SpringSource for more details. The slides suggested the link http://www.springsource.org/web , but that site didn’t exist when I tried to go there. Still, there’s tons of documentation on all the projects at the base URL.
It turned out there wasn’t time for much information about the other areas, but I did note that Spring JavaScript is really a spring-enabled front end on dojo, which is pretty cool.
(I can’t help automatically going, “Pain … does not exist … in this dojo!” Hopefully Spring JavaScript is also painless.)
It also turns out that the amount of configuration to get Spring Security working has been reduced dramatically. That can only be good news.
In the end, I’d say that Spring definitely lived up to its “Swiss Army Chainsaw” reputation, but I liked a lot of what I saw.
(I especially liked the introduction to Spring Roo that I saw later. See below for that.)
The next talk I attended was “Introduction to Griffon” by Danno Ferrin. I was torn there, because I really wanted to go see Paul King talk about Spring and web services, but I knew most of what Paul was going to say already. Besides, I can probably harass him with questions about the rest (no pun intended) tomorrow. 🙂
I do know something about Griffon. It started off as an offshoot of the Grails project, with the same value proposition: bring ease of development and convention over configuration to desktop development. I’ve had long email exchanges with Andres Almiray about Swing development, especially with Groovy’s SwingBuilder and working on and off the Event Dispatch Thread, which I’ve written about here a few times. I’ve only run the basic demos on Griffon, though, and hadn’t seen it presented in any official way yet.
Griffon is all about enforcing MVC architecture with desktop apps. It looks and feels a lot like Grails, but there are important differences. The project is only at version 0.2 (and only a beta for that at the moment), so it’s really early. Still, the basics of “MVC groups” (Danno wanted a better term for them, but I kind of like that one), event handling, deployment, and more are already in place.
The deployment story rocks, by the way. You can export your app as a jar file, as an applet, or even as a Java Web Start application automatically, and it’ll help you digitally sign the jars. That’s really cool. The whole technology is pretty slick, actually. It’s pretty much the only framework for desktop apps I know, though I believe there are a few in development. I suggest that anyone interested in desktop development (and there are far more people like that than most developers think) to check it out at its home page.
By the way, Danno had a great line that I just have to use in the future. He said at some point in the presentation he might have to switch from Bob Ross mode to Julia Child mode, meaning he wasn’t necessarily going to have enough time to paint in front of us, but rather would have to pull completed meals out of the oven. I knew exactly what he meant. 🙂
My feeling about Griffon is that it’s great, but it’s still very early in the development cycle and the documentation isn’t sufficient yet for actual work by people who aren’t closely involved in the project. On the other hand, Danno, Andres, and James Williams (not here) are all co-authors on the upcoming “Griffon in Action” book from Manning. I suspect that book will be as important to future Griffon developers as “Groovy in Action” was (and is) to Groovy developers.
** update: James’s last name is Williams, of course. Also, he’s not a co-author on the book. He is a core committer on the Griffon project. **
The next talk I attended was Paul King’s presentation of “Industrial Strength Groovy.” As he explained, some of the reluctance to adopt Groovy that he finds in the business world is a fear that they won’t be able to use the tools they already adopted and really like. Paul went through a range of tool categories showing how that wasn’t the case.
He discussed lots of testing tools, including mocks like MockFor (built into Groovy), GMock, and EasyMock; injection with Spring or Guice; code coverage with Cobertura; build tools like Ant, Gant, GMaven, and Gradle, Hudson continuous integration, and lots more.
Here’s the best part, at least as far as you, the outside reader, is concerned. You can see all of Paul’s slides on SlideShare.
As an aside, I’m of the opinion that anything Paul writes is great. He has an excellent introductory tutorial for Groovy online in PDF form. He’s also a co-author on GinA (Groovy in Action), which doesn’t surprise me at all.
For the next talk I switched back to the Spring side and attended “Introduction to Spring Roo” by Ben Alex. Ben founded the Roo project, and as it turned out he also founded the Spring Security project. That’s quite a resume. He’s also an outstanding presenter. He doesn’t go for rah-rah tricks or false enthusiasm. Instead he has a very friendly, comfortable, low-pressure style that I find quite appealing. He reminds me a lot of Jason Rudolph that way, or even Guillaume Laforge.
I’d heard of Spring Roo, but didn’t know any details. My original thought was, “oh no, not another Java framework,” but decided to give Roo a try.
Let me just say flat out that I was very impressed. Roo’s best feature (okay, best is a strong term — one of its best features) is that it operates as an interactive command-line application with lots of help and hints available. You start up Roo at the command line (or in STS), type “hint”, and it tells you what it’s expecting next. Just keep hitting the TAB key to get more suggestions.
Essentially what Roo is about is building and configuring a Maven project with lots of AspectJ code generation to modify the source. It felt a lot like Grails, but using Java instead, and most of the code generation affected what happens at compile time rather than at run time. For example, it automatically generates getters and setters and toString() methods for domain objects. It generates the same sort of dynamic finders that Grails has, though you have to choose to add them. It automatically configures Spring JavaScript to do form validation. It uses the JSR 303 bean validation annotations to enforce what it wants. It configures databases for you, too.
I couldn’t help but feel that the Grails framework has been highly influential inside SpringSource. I can only assume that’s partly because Graeme Rocher is now one of their employees (after they bought G2One). At any rate, this was the first Java-based framework that I thought could provide serious competition to Grails. I still like Grails partly because I really like Groovy, and I think it’s always easier to implement anything in Groovy than in Java. Also, Grails has about 300 plugins at the moment, that do basically everything. But if you’re committed to Java, Roo looks like a great alternative. You can download it at the project page at SpringSource.
I only had a couple of criticisms. One was that you can replay your Roo scripts, which is cool, but there’s no way to automatically record them as you go. Expect that to change, since everybody seemed to want it.
The other came from the fact that I downloaded Roo while Ben was talking and was running the app along with him. Then, when typed
roo> perform eclipse
to generate an Eclipse project, I did the same and had to wait about 15 minutes (literally — that’s an estimate) while the underlying Maven engine downloaded the Internet. When I went to test the app in Tomcat, I exited Roo and typed “mvn tomcat:run” and waited again for tons more downloads, even though I have both Tomcat 6 and Tomcat 5.5 on my hard drive already. Finally, when I tried out the Selenium support (another great feature, btw) and ran “mvn selenium:selenese” I had to wait again as Maven did its thing. They all worked, and the delays all had to do with Maven rather than Roo, but yikes nevertheless.
Right now Roo is at version 1.0.0.RC2 and should be at GA some time in December, and that one will include docs. Until then it’s mostly blog posts and the associated forums. I’m definitely going to try Roo, though, when it’s ready.
This post has already gone on too long, so I think I’ll leave it at that. I’m enjoying the conference and am looking forward to more presentations tomorrow.
Leave a Reply