Spent the day at the SpringSource S2G forum, basically a one-day conference by Spring Source. It was a good experience for me - a good fit for things that I've got going on or am thinking about these days - and helped clarify for me what the SpringSource guys are trying to do with the proliferation of products I've complained about in the past.

In short, Spring's focus is on improving developer productivity, and to enable portability of applications. The appeal of the original Spring Framework was that it was much simpler and more productive than EJB, and Spring's architecture is designed from the ground up to let you plug in alternative implementations, whether it's the various bits of the presentation layer, persistence layer, transactions, web services, you name it. Roo and Grails are two different approaches, with different use cases, to bring the kind of productivity improvements seen in Rails and similar newcomers to the development platform scene to the Java platform.

STS is really the centrepiece of Spring's efforts to improve developer productivity, both by providing a pre-packaged set of Eclipse plugins to work with Spring applications, and also as a way to tie together the various parts of the Spring portfolio, such as Grails and Roo, and the various operations-side pieces like TC Server, Hyperic, and even the cloud platforms Spring is working on. The presenters at S2G all used STS, which was an effective way of showing how to get the best out of it and the specific technologies being demonstrated.

Rod Johnson's keynote was heavily focused on the cloud, in the wake of the recent announcement of VMforce and discussion of their cloud strategy. Johnson explained how cloud fits into Spring's strategic focus, which goes back to improving developer productivity, and portability of applications. It really does make sense for Spring to make a push into the cloud, since otherwise the Java platform will be left in the dust by Azure in the enterprise space.

The cloud, and PaaS in particular, is about making life easier for developers, and I know that I am certainly in the market for a way to move my J2EE applications into the cloud. At present, the only real option is to roll your own PaaS on top of an IaaS like EC2, which is a lot of work.

So Spring Source's Cloud Foundry, VMforce, and the other offerings that seem to be in the pipeline will really hit the spot. And they do more than just offering an Azure equivalent, but true to the Spring philosophy, they give us alternatives, whether it's different services to host on, or even the option to deploy a PaaS in our own data centre. So we'll have portability, even the capability to deploy our applications across multiple cloud providers simultaneously. I'm sure that the market for helping enterprises create private clouds will be big, even if it's not "pure" Cloud.

There were a number of other points Johnson made about Cloud that really hit the mark with me. I'm definitely keeping an eye on this space.

Chris Wong responded to the reactions of several dzone commenters to my post on Spring's weightiness.

Chris takes up the question that several commenters raised on dzone, i.e. how do we define 'lightweight' when considering whether Spring still is. He digs back to Rod Johnson's original mission statement for Spring, and concludes that Spring still does meet those criteria.

I think he's right. What I was whining about in my post was really not that Spring, as a framework, is no longer a lightweight platform. It is, and is still my starting point when building an app of more than trivial size.

My moaning was really about the ecosystem of enterprise solutions that Spring Source has built up around the framework. Trying to figure out what these various things actually are is a pain. There is a lot of useful stuff there, but it requires a pretty heavy investment, in both time and cash, to work out what it all is, which parts may be useful to my organization, and how to fit them into our architecture.

On the plus side, it's all still open source at it's core, so once we do work out what's what, we have plenty of choice about how to use it. If our needs are more complex, and our budget larger, it's worth looking at splashing out for the enterprisey, supported versions that Spring Source offers. Having played with Roo, and investigated Spring Integration and other web services pieces, it's clear they're still a pragmatic, dare I say it, lightweight alternative to the stuff put out by the likes of IBM, HP, and Oracle, and one that's still acceptable to pointy-haired bosses.

What's truly key is that if our technical strategy favours the use of lighter, open source components, the Spring folks are still putting out stuff that meets our needs. Hopefully they won't lose sight of that.

The Spring Framework emerged as the lightweight alternative to EJB for Java developers. It was simple, sensible, and had low overhead for designing, developing, and running applications. Over time it has grown from the platform of choice of subversive, technically-driven teams who want to get things done effectively, into the platform of choice for Enterprise Java development teams.

This is great, the best technology has won. But now Spring has become a serious company, and acquired by a bigger company which itself is majority owned by a massive company. And on the way, it's become something which smells to me like an Enterprise Solution.

I'm not talking about the corporate structure - I've got no problem with that in itself. And I'm not talking about the core framework itself, or even the family of extra components that have been acquired. I'm trying to get my head around the development suites, the application servers, the other application servers, (and now I see they even have a web server?).

Now, I have great respect for the guys who developed a lightweight Java platform that the pointy haired boss will sign off on using for corporate projects. If they are similarly packaging quality, useful open source software like Eclipse, Tomcat, and OSGi server, and so on, so that it makes life easier for designing, developing, and running well-engineered applications based on the principles of simplicity, then rock on, let me at it.

But I can't make heads or tails of the Spring Source suite of solution offerings. I have a look at the pricing, and I can't see the practical difference between these and offerings from IBM and the rest. What I do see is going down this road makes my cloud strategy awkward. I can't dynamically add and remove server images in response to useage requirements if I have to count the CPU's and pay a thousands of bucks every time I do so (waiting for the purchase to be approved by corporate each time). So it's not very lightweight from that perspective.

And I can't even work out what each Spring Source product does and whether it makes sense for me to even consider spending the cash, I quickly get bogged down by solution-speak every time I try to get a quick understanding. Then I saw a notice about Discovery Days, and hey! a day-long seminar which goes over the various Spring Source solution offerings and explains what the hell they are, sounds perfect. Oh, wait, it costs £400. They want me to pay to go to their sales presentation.

Bleh.