Gradle plugin for Eclipse

Is anyone picking up management of the Gradle plugin for Eclipse now that Pivotal have orphaned it?


The Gradle Plugin for eclipse now lives at

1 Like

Is there a reason why the update site URL is release specific rather than allowing for automated updates as per normal?

Hi Russel,

We are not working with the code from Pivotal. The Buildship plugin is written from scratch by the Gradleware Tooling team.

The update site you see on points to a milestone build which is a static resource. If you are interested in the latest version, please check out the project’s GitHub repository. In the you will find the update site URLs pointing to the latest CI builds which have the format you described.


For me when using the link Eclipse requests login for, is this normal?

I don’t have account there :smile:

Just using login name guest seems to work.

From what I can see Buildship does not have “create a Gradle project” as the Pivotal plugin did. Is there a document anywhere that presents what functionality there is. I have switched to using the snapshot build.

Hi Bernát

Using guest/guest to connect to our CI update site will do the trick. I’ve just updated the documentation accordingly.

Regards, Etienne

Hi Russel

I will add a document with the current functionality very soon. Please note that we are still at the beginning of all the things that we are going to put into Buildship.

Most of the currently planned items for the future are listed here:

Regards, Etienne


Here is a brief overview of the current functionality:


What?? I knew about Pivotal being ending support for Groovy, GGTS and Groovy-Eclipse, but I didn’t know they are about to end the support even for the Gradle plugin!! This is a REAL problem for my team… Even if we decide to replace Groovy code with Java (in the worst case that nobody takes Groovy-Eclipse on) I really don’t want to lose the benefits I got with Gradle and its current Eclipse integration provided by the Pivotal plugin :frowning:

So, it’s good news to know that Gradleware is taking care of this, also because previous involvement in the Eclipse tooling was quite low…

I would have just one request to the new team: could you please implement a container-based way to handle dependencies like it has the Pivotal plugin, which does not pollute the .classpath file (which we usually share among our team!) with local absolute paths to every JAR a Gradle project depends on?
This would be an extremely important feature.
Also, it would be a very good opportunity to finally fix the mapping between Gradle project dependencies and Eclipse project dependencies in a multi-project environment (see GRADLE-2123 for instance).

The latest version of the plugin already makes use of the classpath container. Also, resolving proper dependencies for the multi-project builds is one of the key elements in the user experience we’ll deliver.

Note that for Eclipse Mars, our focus is on Java projects and not on Web projects.

@donat this is great news, thank you. I look forward to testing something. After reading it was not clear to me that this was already implemented.

@etiennestuder I see, I think that having a first class Java project support first would be a great result already. My only hope is that a better integration with Dynamic Web Projects won’t be forgotten then: it has always been somewhat overcomplicated, even with the STS Gradle Plugin.

Pivotal is indeed planning to somehow transition out of providing our own version of Gradle Eclipse tooling. But that won’t be immediate and we have not dropped support yet, contrary to what was suggested above in this thread.

Basically we were aware of BuildShip being in the works and we are waiting to see how Gradle’s own Eclipse tooling is going to shape up to fill our needs instead. In the mean time we are still continuing to support our own Gradle tooling for Eclipse.

So for the time being you can continue to use Pivotal’s Gradle tooling, but you should be starting to evaluate whether BuildShip can be a suitable replacement and start filing bug/feature requests where you find it lacking.

The transition maybe be a somewhat bumpy ride, but In the long run I beleave it will be for the best.

I’d like to echo a Mauro’s sentiment and extend that. Very few ‘real’ project are just plain Java projects. Maybe they use some AspectJ, or some Groovy, or some annotation processors or…

It has always been a struggle to work with non-trivial projects in Gradle + Eclipse as the Tooling API never really supported that. Pivotal tooling ‘solves’ this by doing a ‘Frankenstein’ approach where the Gradle eclipse tasks are executed during import and on refresh to cover the bits not covered by the tooling API and use tooling API only for Dependencies in classpath container.

This solution isn’t great but at least it works to some degree.

I fear that with Gradle’s declared focus on ‘just Java projects’ the tooling will, for the time being, be of limited use in practice for all those ‘real’ projects that are only 90% Java and 10% ‘special requirements’.

Thanks for your feedback, Kris. Our initial focus on pure Java projects is primarily based by time and resource constraints. Once we have solid Java support, Web-support is next.

Thanks for these insights, Kris. Great to see that Gradle/Pivotal is not dropped like a rock.

Hi everyone,

great to see that buildship is gaining track so quickly after its inception.

One of the things I would expect of buildship is a nice editor. I’ve started a discussion about whether the Minimalist Gradle Editor should live outside of Nodeclipse. From my perspective, transforming it into one of buildship’s plugins could kill two birds with one stone.

It would increase the editor’s integration into the gradle/eclipse ecosystem and enrich buildship’s feature set.

What do you think?

That would be really good, we’ll definitely investigate this option. Could you please give me some pointers on how to get started with the code?