Martin Lippert on the newly released SpringSource Tool Suite 2.6

Posted by Mike Bria on Jun 07, 2011

Sections

Development

Topics

Java ,

Groovy ,

Languages ,

Websphere ,

Programming ,

IBM ,

Application Servers ,

Dynamic Languages ,

Cloud Foundry ,

Companies ,

Agile in the Enterprise ,

Tools ,

VMWare ,

IDE ,

Spring Roo ,

Agile ,

SpringSource tc Server ,

Grails ,

SpringSource Tool Suite

Martin Lippert at VMWare's SpringSource recently announced the 2.6.0 and 2.6.1 releases of their Eclipse-based development environment for building Spring applications, SpringSource Tool Suite. The new release is full with new features, and tracks the latest versions of various projects like Spring Roo 1.1.4, Eclipse Helios SR2, Groovy 1.7.8, Grails 1.3.7. It includes updated support and performance improvements for both Spring Roo and Groovy on Grails, a graphical editor for Spring Web Flow, and new support for content assist, quick fixes and refactorings for Spring annotations

InfoQ caught up with Martin to have him personally walk us through what developers can look forward to with this new release, and more.

Mike Bria, for InfoQ: What's new to help programmers with using Spring's annotation-based meta-programming?

Martin Lippert, at SpringSource:

Since more and more Spring developers are shifting from XML-based configuration to annotation-based Spring programming, we try to provide the same level of support for annotation-based Spring programming as we did in the past for working with Spring config files in an XML editor.

For the first steps we focused on @Autowired, @Qualifier for the configuration part and implemented a lot of support for controllers. So you now have auto-completion and content-assist avaiable in the Java editor for Spring annotations, just as you are used to when working with standard Java code. @RequestMapping is particularly nice; it contains auto-completion and content-assist while typing in path variables, quick-fixes for missing or not-exactly-matching variables, and even refactoring support. So when you rename a parameter that is also automatically mapped by its name to a path variable, the path variable in the annotation is changed automatically as well.

The goal is to avoid any additional views or specialized editors for those annotations; we let the developer stay within the Java editor and provide as much help as possible while working within the Java code.

InfoQ: What other new refactoring tools and capabilities are available (outside those for annotations)?

Prior to this newest release we already provided a huge number of automated refactorings. You can rename bean ids, properties, etc. and all your changes are reflected within your Spring configuration XML. Even if you rename a method that is declared as an @Bean method, references to that bean are automatically changed in your Spring configurations. Nevertheless we have been working hard to provide further improvements. With 2.6.0 we added refactoring support for the p-namespace and for renaming advice and pointcut definitions. It's also important to note that we've got a lot planned in this area for the next release.

InfoQ: Could you tell us about the new graphical Web Flow editor?

With 2.6.0 we introduced an all new graphical editor for Spring Webflow. We worked hard with the webflow team to get a visual editor in place that really shows what you want and need to see when working with webflow. Even better, if you don't like the standard layout we've designed, just change it - its completely configurable! You should take a look at it. It really is beautiful.

InfoQ: This release improves capabilities for both Spring Roo and Groovy on Grails. Can you expand on what's new?

We're always working to include and fully support the latest versions of Spring Roo. This is the reason why we shipped 2.6.0.SR1 on April 12th and 2.6.1.SR1 on May 18th. And we will continue to ship new service-refresh releases alongside new Roo releases. In general, basic Roo support is pretty stable and mature as it stands.

There is quite a bit going on in the Groovy and Grails area, so we're working hard to provide the best developer experience for Grails available anywhere!. To this end, we've improved the underlying Groovy-as-a-language support for Eclipse a lot by adding better (and more configurable) syntax highlighting, refactoring improvements like 'inline renaming', preliminary support for Groovy++, plus a few compilation performance improvements. On the Grails side we've added support for navigation to tag definitions from gsps. We've also added menu access to directly invoke the new grails artifact wizards and, where possible, ensured those wizards are pre-populated based on the context. We believe this makes Grails development a quite a lot more enjoyable.

InfoQ: Deploying to Cloud-based environments is a growing need for many developers. How does this latest release help with this?

Together with the big Cloud Foundry announcement on April 12th, we also released STS support for Cloud Foundry. This allows developers who are using Cloud Foundry as their cloud of choice to deploy their apps directly from within STS into a cloud environment. This works equally well whether you're targeting the full-fledged hosted cloud on cloudfoundry.com or a local micro-cloud in your development environment, even on your developer machine. You can start and stop your apps in the cloud, assign services to them, browse the remote file system, do things like this directly from within STS.

InfoQ: ToolSuite 2.5 saw the introduction of 'Agent-based reloading'. I don't think many developers are aware of this feature, or at least not fully aware of what it provides them. Could you tell us about this feature, and whether there's anything new with 2.6?

"Agent-based-reloading" is a great feature. But its still in its early stages, which is why we haven't advertised it heavily at this point. It allows you to dramatically reduce the time spent waiting for apps to redeploy when working with tc Server. When agent-based reloading is enabled for your app running inside tc Server, many code changes that you make are reflected immediately in the running application, without requiring a server restart.

This of course sounds similar to hot-code-replacement when debugging Java apps, but goes far beyond that. With agent-based reloading, you can add/remove/change methods and even fields while your app is running. The agent takes care to push those changes into the running app without losing the state of your objects; all without any restart or redeploy of your app, or restart of the server.

I should repeat, it is still in an early state, but we are working to continuously improve it - the main focus area for us in the near-term will be ensuring changes to the spring configurations are reflected properly in the running application. The latest improvements in this area added support for Groovy and Grails applications.

InfoQ: What can you tell us about enhancements around the AspectJ Dev Tools in this release?

You could say that the main drivers for the more recent features/changes in AJDT have been for Spring Roo and the Spring Data project. This is because both heavily employ aspects, although in quite different ways; for example, Spring-Data has been making heavy use of generic aspects.

All these changes strive to enable a smoother experience in the editor when working with AspectJ code, by ensuring any action you might attempt is aware that AspectJ constructs are being used. For example, search/refactoring operations being aware of intertype declarations and doing the right thing with them.

InfoQ: Also related to AspectJ, you've made some changes with JDT weaving. Can you expand on that?

Relatively recently we actually turned on JDT weaving by default. JDT weaving is what AJDT uses to 'open up' eclipse a little more so that UI extensions (like AJDT) can do what they need to do. JDT weaving actually uses AspectJ to weave into Eclipse as it starts up, using the technology developed under the Equinox Aspects incubator project. We have been using this technology for a while but it was always 'opt-in' - but in the recent release it is now on by default, since the technology we are using has proven itself reliable and robust.

InfoQ: Word is that the group behind ToolSuite utilizes a disciplined agile process with a relatively distributed team. Could you expand a bit on the key aspects of how you do this?

The development team behind STS is indeed a globally distributed team. We work mostly from Canada and Germany, but the team is spread out across 5 cities in total and we utilize an agile approach. We have a somewhat customized agile process combining techniques from Scrum and Kanban, so we have a prioritized backlog that we continuously work on, and we have daily scrums that we do over Skype, to name just a few.

But I think the most prominent and visible change to the outside world is our release cycle. We moved towards shipping a new STS version roughly every three months, including two public milestone builds in between. This allows us to ship new features and other improvements on a very regular basis. People who are highly interested in those new features can then even use the milestone builds to get their hands on it early. We would love to get even more people from the huge Spring community involved in this process. Feedback is essential for us working on developer tools, and so any feedback or suggestions from the community are absolutely priceless to us.

InfoQ: Finally, what's hot on the backlog for upcoming releases? What can developers expect next?

We are working hard on improving the Cloud Foundry integration at the moment, proving even deeper integration between Cloud Foundry and STS. And the next big thing will of course be the support for the upcoming 3.1 version of the core Spring framework. The support for the new "profiles" feature will be especially great, you'll love it.

Also In the pipeline for 2.7 we have been working closely with the Gradle team to provide Gradle support for Eclipse. And we are going further with our refactoring support in Grails, enabling smart rename refactorings that understand the relationship between artifacts and can rename them all together (simple example: renaming your domain class tests when you rename your domain class).

We are also opening up Groovy-Eclipse to make it more easily extensible by anyone working with a custom DSL - by contributing a simple piece of groovy it will be possible to extend the built-in inferencing and code-assist capabilities of the groovy editor. We'll be exploiting this feature ourselves when supporting the many varied DSLs utilized throughout Grails. We really believe this can open-up huge possibilities.

Thanks Martin!

1. Back to top

   Message from the future?

   by Anton Arhipov

   I see that the date of the article is 30 june 2011, right now its june 6 2011.

   Reply

2. Back to top

   Re: Message from the future?

   by Mike Bria

   Hi Anton,
   
   Yes, actually it is. We've taken the article down from the main site while we enhance this, its only accessible directly at this URI now, which I'll also be undoing after responding with this message. FWIW, all items in the interview are true as of 6/6, just not the "latest greatest".
   
   Thanks, Mike & Martin.

   Reply

3. Back to top

   Re: Message from the future?

   by Mike Bria

   Everything's back on track, redated, reposted now.
   
   Thanks,
   Mike

   Reply

• Older >