When does Buildship/Eclipse customization run?

Help/Discuss Buildship
1

I need some help understanding when Eclipse customizations run. I imagined that when I have something like this:

eclipse {
  jdt {
    file { 
      withProperties { properties ->
        properties["..."] = "enabled"
      }
    }
  }
}

in my build.gradle file, that the JDT property manipulation would happen (i.e., I would see that .settings/org.eclipse.buildship.core.prefs gets updated) when I import the Gradle project into Eclipse and when I do Gradle>Refresh Gradle Project. However that seems not to be the case. It doesn’t happen when I do a command-line Gradle invocation either unless I do gradle eclipse. Is that the expected behavior?

2

Buildship does not use the withProperties and withXml hooks (they are file-based, while Buildship is model-based). What Buildship needs is a proper model of Eclipse preference files (not just for JDT). If you (or someone else) are interested in contributing that, I’d be happy to guide you through the process.

3

So is the bottom line for now that I should tell my fellow devs who I might want to convert to using Buildship that they should just do “gradlew eclipse” as part of setting up their environment?

WRT contributing: I’d love to help out (and maybe I will at some point), but first I’d need to learn Gradle, Groovy, and Buildship more than the tiny bit I’ve learned from doing my present exercise, which is to get a large Gradle-based multi-project code base importing into Eclipse using Buildship :slight_smile: (Right now we’re using a single pair of manually-maintained .classpath and .project files that span all the source directories across all the Gradle projects, which has all the problems you might imagine it would.)

Thanks.

4

There are two workarounds for now:

  • run gradle eclipseJdt after you import (please never run the full gradle eclipse task when using Buildship, the two are incompatible)
  • check in your org.eclipse.jdt.core.prefs

You don’t need to manually maintain .project/.classpath. Everything in those two files can be modelled in the Gradle build and is understood by Buildship.

5

RIght, I’m exactly trying to stop manually maintaining our problematic uber-.classpath file (that doesn’t actually properly capture the dependencies that are expressed in the Gradle build scripts) by switching over to Buildship.

WRT checking in the org.eclipse.jdt.core.prefs file: Since we have a lot of projects, that’d turn into a lot of (identical, or close to it) such files that would have to be kept in sync. So the first workaround seems better, unless you have any suggestions on how to make the second one not painful.

Thanks for your help.

6

You’d generate the files using the eclipseJdt task, no need to keep them in sync manually. You just rerun the task when you want to change something across all projects.