How to change the Gradle version of buildship globally?

Help/Discuss
1

We want switch all our project to a defined Gradle version:

We have add the follow to our central base script plugin.

task wrapper(type: Wrapper) {
gradleVersion = ‘3.1’
}

But If I click “Refresh Gradle Project” then the variable gradle.gradleVersion has the value 1.14.1.

I use Buildship 1.0.21.

In the file org.eclipse.buildship.core.prefs of all projects there is:
connection.gradle.distribution=GRADLE_DISTRIBUTION(WRAPPER)

If I run a build task then I can change the version in the run configuration.

What must we do to switch to a defined Gradle version for Buildship project refresh.

2

This is not specific to Buildship, but how the wrapper works:

The wrapper task does not define the version of Gradle, it is just a utility to update it. You have to actually run the wrapper task to re-generate the wrapper.properties file.

3

Thank you for the answer. But the wrapper.properties is also pro project. Is there a central setting with which I can trigger Buildship to use the same Gradle version if not other set? A default Gradle version.

4

This is intended. Each project should define which Gradle version it uses.

A setting in Buildship wouldn’t help. You’d get a different version on the command line/build server if you don’t configure the wrapper properly. You want the same reproducible build everywhere.

5

You want the same reproducible build everywhere.

This is the point. That we want set the version centrally. Our projects contains only a very small build file which has no version relevance. But this projects apply a very large shared script plugins. This global code base depends on the version of Gradle. That we have the requirement to switch all projects in one branch.

For the build system this is not a problem because we have also checkin which Docker swarm is used.

6

Did I understand correctly that you are applying a remote script which changes over time?

7

No, not a remote script. A Gradle build script project. This is parallel to all the other projects. If a project will be branch then this project will also be branch.

8

Could you create an example of your project structure on GitHub? I’m afraid I don’t understand it yet.

9

It is not a git repository. It is a SVN repository. The location in the repository is not relevant. To build you need to checkout 2 projects in one root folder. The script project with the build environment and the real project.

buildScrpits\
  base.gradle
  xyz.gradle
project1\
  build.gradle
project2\
  build.gradle
project3\
  build.gradle
10

With that structure it would be very easy to update the wrapper for all projects in one batch:

  • check out the top level folder containing all the projects
  • update the wrapper in the buildscripts project
  • run a task that copies the wrapper from buildscripts into all the projectXXX directories
  • check everything back in
11

What is easy on this steps?

  • First it will take hours or days to checkout all the projects.
  • There is no warranty that we does not forgot some projects.
  • The size of data of all projects would break the capacity of the hard disks of the developer systems.
  • The checkin of every single project would also need hours.
  • The checkin in every project would trigger the continuous build of every project. This would run multiple days and block the normal work.
12

Is there a solution for this?
We have the same problem?

13

The solution is to use the Gradle wrapper. All Gradle builds should use the wrapper, otherwise they are not reproducible.

Changing the build logic is a change that needs to be tested. Otherwise you are just pushing stuff onto the developers without even knowing if it’s gonna break their build.

I recommend building a custom Gradle distribution containing your script plugins and referencing that custom distribution in all wrappers. Then either the developers update it on demand or you have a CI job that does it automatically as I outlined before. You could even add a check in your custom plugin which fails the build if a newer version of that plugin is available.

14

I recommend building a custom Gradle distribution containing your script plugins and referencing that custom distribution in all wrappers. Then either the developers update it on demand or you have a CI job that does it automatically as I outlined before. You could even add a check in your custom plugin which fails the build if a newer version of that plugin is available.

This does not solve the problem of the branches. Also the company base build scripts can change frequently. There can change server name, passwords, etc. This would produce a large count of distributions every day. Also on testing the developer can change for debugging some things on the scripts. And I have no idea how I create such distribution.

15

Is there a solution for this?

Our current solution is to break the Gradle script with an exact error message and handling tips for the develiopers if the running Gradle version is wrong.

The next step will be to patch the file .settings/org.eclipse.buildship.core.prefs if exists. The result is that Gradle Job fail only on the first run.

connection.gradle.distribution=GRADLE_DISTRIBUTION(VERSION(3.1))

This logic is saved in our base Gradle script.

16

Instead of patching the .prefs file (which is an implementation detail of Buildship and will likely change), you could patch the wrapper.properties and save yourself some headache. Just check what Gradle version you’re running on, patch the wrapper.properties and fail if it was the the wrong version. That’s exactly what I meant above with an “on demand” update.