Buildship, eclipse plug-in, multiproject builds




I am fairly new to Gradle and buildship and I have a bunch of clarification question I hope someone could help me a bit with.
First the scenario, I have migrated a complex j2ee application (made of around 100 projects) to buildship.
I have created a multi project structure that given the directory layout is only usable from the root project. The layout it:
/root/root/settings.gradle + build.gradle


  1. I have added to my root build.gradle the follwing. Is it necessary at all to add the eclipse plugin?

    allprojects {
    apply plugin: ‘eclipse’

  2. Maybe is due to me running gradle eclipse, but I noticed that it seems that my projects forget they have got a “Gradle Nature”. To fix that I have added in my root build.gradle the follwing. Bad idea? Unnecessary?

    allprojects {
    apply plugin: ‘eclipse’
    eclipse.project {
    natures ‘org.eclipse.buildship.core.gradleprojectnature’

  3. After adding more and more projects to my build, the “Gradle Tasks” view in eclipse behaves strangely.
    Few Nodes can be expanded, but most of them are marked with a red x indicating an error. Notice that my gradle build work without problem from command line
    In addition, at a certain moment I noticed that my subproject showed up twice. Once picked up from the root project and they shoed all tasks inherited from root. The second instance of the project seemed coming from buildship picking up the sub project alone (the node was lacking og most task groups)

I hope my post is understandable enough, I can elaborate on all points and provide more info if necessary

Thanks a lot

(Stefan Oehme) #2

Only if you want to do customizations to the Eclipse model that Buildship uses.

If you use Buildship, don’t run gradle eclipse. They are mutually exclusive.

Since you have a non-standard project layout, you always need to refresh the root when adding new subprojects. Gradle can’t find the root by itself and will treat the subprojects as standalone projects, which are then usually broken because they lack configuration.


Ok, got it, could you give an example of customization so I can understand better? I.e. I also have this code in my root.gradle to ensure that the websphere application server facet is applied. Is that what you mean by “customization of the Eclipse model”?

subprojects {
	def configureFacets = { 
		eclipse.wtp.facet {
			facet name: '', version: '8.5'
			facet name: '', version: '8.5'

Ok, but I have an issue about the eclipse .project, .classpath and .setting/ files. All projects are managed under git and these files are ignored (used a .ignore file created with specifing gradle,eclipse and java)
This means that when a developer checks out the project for the first time, there is no .project file and the project cannot be openend in eclipse.
I thought that the solution was to check out all projects then move to the root project and run gradle eclipse from the command line.
Is the correct procedure?

There is aslo a matter of speed. Running “gradle eclipse” from the root project is blazing fast, while right clicking on the root project and choosing “Gradle ->refresh gradle project” takes forever with my 100 projects build

That makes sense, but what I see is actually the opposite, the root project and others show up as non explandable notes with error, some other projects are expandable nodes without probelms but clearly disconnected from the root project.
Am I maybe hitting some kind of limitation due to the amount and size of the projects?


I have actually fixed this bit.

  1. run gradle eclipseClean from the command line
  2. removed the root project from the eclipse workspace
  3. used import -> Existing Gradle Project
  4. Now the project structure is nice and clean inside the “Gradle Tasks” view and there are no duplicates or errors
    Still to be able to open the subprojects (now “cleaned”) in eclipse and work on them I need to run the “Eclipse” task from the Gradle Tasks view, right?

(Stefan Oehme) #5

Exactly :slight_smile:

No, the developer should use “Import Gradle Project”.

It should be exactly the same, can you reproduce this with a project you can share?

No, the subprojects will be imported together with the root and should be ready to use.


Thanks a lot Stefan!,

you really made a lot of things clear for me!
Regarding the speed, I am afraid I cannot share the project. But if I can isolate the issue I will open problem report