Recorded at:

Bio Christian is a Principal Software Engineer for SpringSource and is the leader of the Tools Team responsible for SpringSource development tools including SpringSource Tool Suite. Since 2004 Christian has led the well known Spring IDE open source project that provides development tools for the Spring Portfolio based on Eclipse.

Sponsored Content

SpringOne 2GX is an annual event; it includes a technical exploration of the Spring ecosystem along with the latest developments in the Groovy/Grails space. As a participant, you will have the opportunity to attend two great events at one venue. Whether you're a Spring enthusiast, Tomcat user, Groovy/Grails fan, or just interested in open source development, you'll find valuable content in sessions presented here.

Sure Ryan. So SpringSource Tool Suite is our integrated Eclipse distribution, which takes our open source components - our open source tooling components - and adds enterprise level features to it. So we offer tools support around Spring, obviously; we also do lots of tooling around enterprise OSGi, for our OSGi runtime called dm Server. We also make sure that we integrate all our runtimes, like just recently announced Cloud Foundry as our cloud offering - tc Server Developer Edition with the very interesting Spring Insight dashboard for example is one of those things.

So it's Spring 3.0, Spring support in general, OSGi support, making sure that people can use our runtimes, and just recently we started to work on Groovy and Grails tooling. The mission of STS is actually written down, and I talked about that during my presentation, is we want to make sure the STS is the best place to develop Spring OSGi applications. We are very close to that point already. We have a very strong position there and now we want to also make sure that people can have the best tooling for Groovy and Grails on the Eclipse platform available.

So, I think first and foremost let me say that usually if you do Groovy and Grails development, and you are not able to use an IDE, IntelliJ IDEA for example, you end up being stuck in TextMate or other text editors. So when G2One came on board with the SpringSource acquisition, we made the promise that we would actually heavily invest to bring quality tooling to the Eclipse platform to provide tools support for Groovy and Grails. Having proper tooling support for the language and for the framework I think is a required driver to really make sure that the adoption can continue at this rate that you see currently with Groovy and Grails.

So having said that, we started out with starting to work on the Groovy Eclipse open source plug-in, which is hosted at Codehaus. So two of the SpringSource employees, Andy Clement and Andrew Eisenberg, essentially the team behind AspectJ and AJDT, started to work on the Groovy compiler within Eclipse. So we took the JDT core compiler, which is the core piece of the Eclipse Java tool, and made sure that this compiler can now also joint compile Groovy files; Groovy classes or scripts. Having this in place actually enables us to leverage lots of the already existing Java IDE UI tooling that exists in Eclipse. So, we are working heavily on this open source project; we are kind of taking over the technical lead of the project; we are driving that project forward in the open source world; and, in parallel, after having reached a very solid state for the language support, we now have very recently started to build Grails tools.

So what that means is you can now take STS, which has been released today to the public, so people can download STS, which is free, install the Grails support, and then they are able to create new Grails projects for Grails 1.1.1, Grails 1.2 Milestone 3, for example - whatever Grails version you want to use. You can try the new Grails Project wizard to get your Grails project running inside the IDE and you get then automatic dependency management, so if you use a Grails plug-in you will get all the JAR files that you need for your project to compile, you also get the source files for the plug-in scripts linked in, and so on and so forth. Combining this with the new joint compiler that we have in the Groovy Eclipse plug-in, it makes a really good experience working with this tool.

You can now implement your Groovy controller or Grails controllers and then being able to use or invoke Grails commands right outside your IDE is also a very big thing, I think, so you can use a shortcut to popup a Grails command window where you can type in your Grails command - for example to create a controller class or maybe to even run your application. So you can do "grails run-app" and this will then launch Grails right inside your IDE, being able to click a link and then browse your application; use the Eclipse built-in debugger facilities to debug and step through your Groovy code. I think that is a very important thing to bring that seamless experience onto the Eclipse platform.

I said earlier that we just recently started with that, so what we just released is like the first step to provide all the tooling for Grails that we think people will need. So there is lots of improvement that we need to work on and will over the coming months, like for example a GSP editor is missing, there should also be some kind of easy facilities to install and update your plug-ins that you use, like a plug-in browser, and so on and so forth. I mean we kind of collect those feature requests now in our Jira. People heavily contribute to this Jira issues, so we see lots of votes, very big community interest in that support and people seem to be excited about what we just released today.

I think for both of those frameworks it is important to say we just started in that area so we will definitely provide UIs for the most common commands - like for example, "create a controller class", which makes sense in both worlds - provide UI functionality for that: so you have a button, press it, "create new controller", ask you for the name, and the package, and then off you go.

I think from a coding perspective it is actually a pretty nice experience: you are in your editor and you want to do something new; you press a shortcut and you get that popup that asks you for the Grails command or the Roo command; and then you are able, without actually using the mouse, to create this artifact - or in the Roo case maybe just even the persistent field on your entity - and then see that right away being refreshed in the Java editor, so that is not actually a very bad user experience in my opinion but you are completely right; we will provide a UI or wizards that will drive people to the most common commands. But having said that, I think it's also very important to know that both Roo and Grails, Grails has a very big plug-in community and so Roo just starts building up this community, and those plug-ins add commands, so we are probably not able to provide a UI for all of those add-on or plug-in commands. But, for the most common cases where you want to do a create class, create entity, create domain class, create controller, tests and so on, we will very likely or very soon have those UIs in place.

I think it's a very interesting question and what we see usually with STS is we see lots of innovation around our open source portfolio, we get new commercial products, and all of those will get integrated into our tooling to make a really seamless experience for developers. So on the core STS roadmap for now and maybe going through the next half year, we will definitely spend some more time to get Cloud Foundry even a better integration into the developer tooling. We will spend - as we discussed already - spend a lot of time on Groovy and Grails to improve that. We will make sure that Spring 3.0 when it finally comes out just will provide all the tools that people need.

We are very close to that point right now, as of the RC1 of Spring 3.0 but there might be changes that we need to incorporate into STS. And then there is dm Server 2.0, which is currently planned for roughly Q4 of '09, so we will need to update our OSGi tooling around that. dm Server comes with lots of new features around how people deploy their applications but also how people provision a dm Server instance so all of this needs to get support in our developer tooling. And then we have two open source portfolio projects, with Spring BlazeDS and Spring Integration, which up to this point have very limited support in our developer tooling. So we will spend time on actually bringing - I think it makes sense in the case of Spring Integration where you have like this integration flow, you have splitters, routers and all that stuff - to actually provide visual editing tools to orchestrate this flow for your integration configuration. So we will work on that and then in conjunction also provide tooling for Spring BlazeDS.

Yes, sure. With all our runtimes what we try to do is integrate that as seamlessly as possible with the Eclipse platform. So all our runtimes actually have a WTP server integration so if you open up the "WTP Servers" view within Eclipse, which is a standard view that comes with the Eclipse platform, or with the Eclipse WTP project, Web Tools Project, you get the choice to use our servers in that infrastructure. So what we do with Cloud Foundry, being not an actual server but more like a cloud offering, a Platform-as-a-Service, you can create a new Cloud Foundry account, so you login with your credentials and then you will see this account being represented in the "Servers" view. You can then connect to Cloud Foundry and, as children in the service view below your account you will actually see all the applications that you already uploaded using different means, like for example the Roo or Grails plug-in or the web UI, and then you can deploy those applications that are already uploaded; you can deploy those, meaning you can actually launch up Amazon EC2 infrastructure and deploy your application to it.

So that is one feature, the other feature is that you can actually take your project out of your Eclipse workspace and deploy that to Cloud Foundry. So you just take your project, drag and drop that onto your Cloud Foundry server in the "Servers" view: you can then right click and say "start", and this will then provision and launch the EC2 infrastructure using Cloud Foundry as the Platform-as-a-Service provider for this.
A next step here is certainly being able to attach debugging sessions to a running instance, for example, or being able to use the Eclipse Data Tools to maybe look in the database that runs on those images - just for developers to be able to actually debug those things, maybe look into the database, do updates, and so on and so forth.

Also what we are looking into is providing this deployment blueprint integration in our tools so people would actually be able to select deployment blueprint out of a catalog of available blueprints that Cloud Foundry offers, and then you can configure those blueprints and deploy an instance of one of those blueprints using the integration. So [deploying a] blueprint what we mean by that is usually, what is your deployment infrastructure, how many application server instances you want to have, what's your load balancer or web server in front of that, what is your database infrastructure, and so on and so forth. That is all described in the development blueprint and you will be able to choose and configure this in your IDE.

First of all I should say we still work very closely with Tasktop. We actually share an office in Vancouver with Tasktop and Mik and his crew, so they are still heavily involved in what we do around STS. Secondly it's an interesting question; we have just started the STS 2.2 version to provide our users a very easy way to install third party extensions into STS. So what we experienced from a support perspective is that people will usually run into issues around updating or installing plug-ins into STS because of P2 fiddling (P2 is the update mechanism in Eclipse), finding update sites and then not being able to resolve dependencies for those third party plug-ins, so we wanted to provide a very easy way for people to install third party extensions.

So what we did here is we took a component out of the Mylyn open source project which is the so called Connector Install, or Connector Discovery, and used that to extend that to install any kind of third party plug-ins, so people now will be able to, when you launch STS you get the STS dashboard which will then feature an additional tab reading "Extensions", and this, once you click that, it will actually read or discover all the extensions that we think and we know that you can install them into STS without problems. And that is actually where we provide access to Groovy and Grails tooling right now, which is in milestone 1; so we actually are not shipping Groovy and Grails right out of the box but making it really easy for people to install. And using that technology people are now also able to install Tasktop Pro or connectors around the Mylyn open source project that are provided by Tasktop.

InfoQ Weekly Newsletter

Join a community of over 250 K senior developers by signing up for our newsletter. If you are based in the EEA, please contact us so we can provide you with the protections afforded to you under EEA protection laws.

Is your profile up-to-date? Please take a moment to review and update.

Email Address

Note: If updating/changing your email, a validation request will be sent

Company name:

Keep current company name

Update Company name to:

Company role:

Keep current company role

Update company role to:

Company size:

Keep current company Size

Update company size to:

Country/Zone:

Keep current country/zone

Update country/zone to:

State/Province/Region:

Keep current state/province/region

Update state/province/region to:

Subscribe to our newsletter?

Subscribe to our architect newsletter?

Subscribe to our industry email notices?

By subscribing to this email, we may send you content based on your previous topic interests. See our privacy notice for details.

You will be sent an email to validate the new email address. This pop-up will close itself in a few moments.

We notice you're using an ad blocker

We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.