SpringSource has announced the release candidate of <a href="<a href="http://www.springsource.com/products/sts">">SpringSource Tool Suite (STS), their branded toolsuite, a set of plugins for Eclipse. It's built on Eclipse Mylyn and includes Spring IDE as a core component, along with adding other features and tutorials (which, incidentally, seem more useful than Spring's base documentation, with respect to OSGi...) Additional SpringSource Tool Suite features include:

• Spring Development Tools for intelligent editing, validating and navigating support for Spring application blueprints
• Mylyn Task-Focused Interface for Java artifacts and Spring configuration files
• Spring Framework explains and highlights new features in Spring Framework 2.5
• Task-Focused Tutorials guiding the developer through the various products in the Spring Portfolio
• Runtime Error Analysis adding explanations and solution suggestions to Java stack traces

Download for a personal use edition beta is free after registration on the SpringSource Tool Suite website. Final release is planned for the end of April 2008. The tool suite actually looks very nice; the tutorials are clear and workable. Good job, fellows. One wonders, though, where one of the S's went - it's listed as STS, not SSTS. :)

The link to the product site seems to be mucked up Anway it's http://www.springsource.com/products/sts

I was getting 5 permgen crashes a day with Ubuntu Edgy, Eclipse 3.2 and SpringIDE. The only option was to uninstall the plugin. I'm now on Gutsy + Eclipse 3.3 and have been running this plugin for the last couple of days without a hitch.

I was getting 5 permgen crashes a day with Ubuntu Edgy, Eclipse 3.2 and SpringIDE. The only option was to uninstall the plugin. I'm now on Gutsy + Eclipse 3.3 and have been running this plugin for the last couple of days without a hitch.

Spoke too soon. 2 permgens and counting :(

Any chance to get such a huge download distributed via Bittorrent? Note to TSS: you got a fancy '<c:out value=..' title of the forgat password page :)

Teams do not realize the application has an 'implicit' dependency on the framework. Ask them a simple question like 'Can you take out spring and replace with something else?'...all that greets you is a blank stare. I am not slating spring here which is truly a remarkable framework but I am just concerned that they seem to be going the Redhat way with all their commercial offerings with an implied message "if you are serious with spring then pay us". What happens tomorrow if spring releases a commercial enterprise ready version for paying customers only? What are the options...pay up quietly / create a fork / switch...

Unlike most other frameworks, Spring does not require your application code to depend on the Spring API. In fact, that's right in their mission statement: http://www.springframework.org/about In fact, we recently did just that: in a complex Swing application that was developed with a lot of dependency injection by Spring, we replaced the Spring initialization with good old constructors and setters again. Now it starts up a lot faster, but it has become a lot more complex to maintain. Of course, I'm talking about spring-core and spring-beans here. For spring-web or spring-orm it's a whole different story.

What I meant was that the application becomes dependent on spring framework for bootstraping, wiring, tx/orm support depending how much you use it. Take spring out and your application is a....dud. As I have already said, I have no problem with the framework but only with the commercial stuff (spring certification , spring IDE) that has started to creep in Spring's offering aka Redhat style. there is nothing stopping them from offering an enterprise version for paying only customers and provide a free "gree field" version for the community. I still remember all the trouble our IT department had to convince the board to shell out a massive fee ( even after having paid for the subscriptions) for something which was once free.....

What I meant was that the application becomes dependent on spring framework for bootstraping, wiring, tx/orm support depending how much you use it. Take spring out and your application is a....dud.

I just don't understand this complaint at all. If you use functionality from a third party library, but then remove the library, your application won't work... and? How is Spring any different and more deserving of criticism for this simple and obvious fact? Try running an application that uses EJBs without a container and funnily enough it won't work. Create a bunch of JUnit tests and try and run them without JUnit - that won't work either. Try leaving log4j, commons-logging and sl4j off your classpath and witness the vast majority of applications fail to run.

You have completely missed the point.If ypu architecture is based on standards (e.g J2EE/EJB) you can easily switch vendors. log4j, JUnit are open source and are backed by the community (no vendor) unlike spring which is controlled solely by interface21. So my rant was not about using third party libraries but about dependency on *proprietry* library from a commercial vendor. Disclaimer: I do not work for JBoss

Although SpringSource does control the direction into which the Spring Framework is heading, I still think that Spring is open-source. On the website of the springframework it is stated that "All Spring projects are licensed under the terms of the Apache License, Version 2.0.", which grants you a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare Derivative Works of, publicly display, publicly perform, sublicense, and distribute the Work and such Derivative Works in Source or Object form. If at any point of time SpringSource release some features under another (paid) licence, which could cause problems for you or your organisation, then you still can get a copy of the current version of the SpringFramework and keep using that. You would miss out on the great enhancements, which the guys of the SpringSource would come up with, but hey: it's your decision not to buy any of that. IMHO: The guys at SpringSource are doing a fine job and are entitled to make some money out of it, especially when they enhance and create a good and integrated IDE. Having that has always repaid itself in reduced development time and effort.

Marco, I understand the Apache License completely.I would like to point out that Open-source != FREE. What is worrying is that spring is heading in the same direction as RedHat in terms of its offering ... a. Use the community to build you product b. Encourage members to adopt in their companies on the free as in beer promise c. Get VC funding d. Scr*w the community and start charging the same users that helped (testing, adoption in their companies, recommend to friends). Now these users and their have have a little choice but to pay for the great enhancements because their architecture is locked-in to a proprietart framework (er...vendor-lockin?) e. Release (expensive) enterprise version and to keep the idiots in the community happy release a besic version... Everyone wins ? Sure buy them and have a permanent vendor-lock in...Do you know that the spring's product are with a bundled in (expensive) support contract ?

You have completely missed the point.If ypu architecture is based on standards (e.g J2EE/EJB) you can easily switch vendors.

Well, easily is a little bit exaggerated. Also, if your architecture is based on a pile of source code (Spring) than why would you ever switch vendors? If you decide to develop based on a particular toolset and architecture you will always be to a certain amount "locked into" that toolset. My main criticism of spring that a lot of people are simply denying that such an (implicit) lock in exists ( because they can't see it in their source code, they think it does not exist 8-O ). I don't care that it is "proprietary" as long as I can work with the source code (if I have to).

Well, easily is a little bit exaggerated

Ok. Agreed. It does take a bit of effort but you do not need to rearchitect.

Also, if your architecture is based on a pile of source code (Spring) than why would you ever switch vendors?

If spring (interface21) goes bust...no new features/enhancements or integration with new technologies.

If you decide to develop based on a particular toolset and architecture you will always be to a certain amount "locked into" that toolset.

Which is different from a (single) vendor lock-in.

My main criticism of spring that a lot of people are simply denying that such an (implicit) lock in exists ( because they can't see it in their source code, they think it does not exist 8-O ).

+1

I don't care that it is "proprietary" as long as I can work with the source code (if I have to).

That option is not for everyone.

Well, easily is a little bit exaggerated

Ok. Agreed. It does take a bit of effort but you do not need to rearchitect.

I am not sure which JEE servers you have been using, there is at least as much work switching between application servers as there is to take an application wired up with Spring and instead deploy it as a JEE application. Sure, EJB3 made things better, but not much better. As soon as you do anything beyond a brainless little application you are into vendor specific teritory. Try finding the TransactionManager in WebSphere and see how much good that does you when using OAS, JBoss, or WebLogic. JNDI naming is still no where near standard as even the EJB3 spec left everything as "recommended." Which loosely translates to "how BEA and the reference implementation will work but nothing else." Drop down to complex ORM mappings or lazy loading territory on JPA and you are again in the realm of vendor uniqueness.

Also, if your architecture is based on a pile of source code (Spring) than why would you ever switch vendors?

If spring (interface21) goes bust...no new features/enhancements or integration with new technologies.

If you decide to develop based on a particular toolset and architecture you will always be to a certain amount "locked into" that toolset.

Which is different from a (single) vendor lock-in.

That is why there is a community. If Spring did something stupid with their technology and forced too much of a commercial direction down everyone's throat, the code would fork very quickly. It behooves them to do more than a "basic version" which you implied would have little utility. Also, this runs counter to their track record. Sure, they now have VCs and are looking to offer commercial versions of some things - but to suddenly deprive the community of essential ingredients would run counter to what Rod and the Spring team have built over the last 4 years. Anything is possible, but such an event is extremely unlikely.

My main criticism of spring that a lot of people are simply denying that such an (implicit) lock in exists ( because they can't see it in their source code, they think it does not exist 8-O ).

+1

I don't care that it is "proprietary" as long as I can work with the source code (if I have to).

That option is not for everyone.

Lockin exist for almost everything. I can think of very few examples where technology lock in does not occur to one degree or another. The important thing is picking a technology with a strong/broad community, reliable committers and a vision that is aligned with yours.

Well, easily is a little bit exaggerated

Ok. Agreed. It does take a bit of effort but you do not need to rearchitect.

I am not sure which JEE servers you have been using, there is at least as much work switching between application servers as there is to take an application wired up with Spring and instead deploy it as a JEE application. Sure, EJB3 made things better, but not much better. As soon as you do anything beyond a brainless little application you are into vendor specific teritory. Try finding the TransactionManager in WebSphere and see how much good that does you when using OAS, JBoss, or WebLogic. JNDI naming is still no where near standard as even the EJB3 spec left everything as "recommended." Which loosely translates to "how BEA and the reference implementation will work but nothing else."

Hmm...We do use mix of both Glassfish and Weblogic. We have loads of J2EE (1.4) and EJb3 stuff and our platform handled more than 6 billion complex financial transactions last year so not exactly a brainless little app...Yes it's not easy but it's not that hard.

That is why there is a community. If Spring did something stupid with their technology and forced too much of a commercial direction down everyone's throat, the code would fork very quickly. It behooves them to do more than a "basic version" which you implied would have little utility. Also, this runs counter to their track record. Sure, they now have VCs and are looking to offer commercial versions of some things - but to suddenly deprive the community of essential ingredients would run counter to what Rod and the Spring team have built over the last 4 years. Anything is possible, but such an event is extremely unlikely.

Ever heard of Redhat?...How many Fedora installations do you know of in production ?

Hmm...We do use mix of both Glassfish and Weblogic. We have loads of J2EE (1.4) and EJb3 stuff and our platform handled more than 6 billion complex financial transactions last year so not exactly a brainless little app...Yes it's not easy but it's not that hard.

You happen to be one of the lucky few. As I mentioned in my post, BEA and Glassfish (Reference Implementation) are the easiest to port between. I do ports between all types of JEE servers and the work is absolutely massive. Try WebSphere to BEA or OAS to BEA and you will find the experience vastly different. Your app definately does not sound brainless, you just have a great environment. Most clients I deal with are pretty diverse.

Ever heard of Redhat?...How many Fedora installations do you know of in production ?

It could possibly happen - but I find it unlikely. There are commercial open source companies that still provide tremendous value to the community while still having some commercial offerings to fund such community development. In fact, most of the open source code that people use is backed by a commercial company in one way or another.

I saw a demo of this at my company last week and we were all very impressed. Having it bundled with a service contract raises the barrier of entry though (internal approvals of support contracts is longer than those to buy a single product). Just something to think about :-)