Wrapper in multi project build


(Klaus Christiansen) #1

I have a multi project build.

something like:
gradle -q projects

Root project 'Foo'
+--- Project ':Bar' 
\--- Project ':Baz'

I would like to create/update wrappers for all projects.
I have this build in Foo

allprojects {
  wrapper {
    gradleVersion = '4.10.3'  
  }
}

But when I run gradle wrapper in Foo nothing happens in Bar and Baz.

How can I archive my goal?

Regards Klaus


(Klaus Christiansen) #2

I figured out how to solve my problem

I added this to my Foo/build.gradle file

allprojects {
    task allWrappers(type: wrapper) {
        gradleVersion = '4.10.3'
    }
}

running gradle allWrappers creates wrapper for all projects. :smiley:


(Dimitar Dimitrov) #3

Just curious why do you need to do this? Normally the wrapper is added only for the root project. Any wrapper settings in subprojects will be ignored in a multi-project build.

Anything I can imagine you doing with multiple wrappers is either brittle, or already possible with a wrapper in the root.


(Klaus Christiansen) #4

I want my developers to be able to build, compile, test, check any projects/sub-projects without having Gradle installed. And they should be able to do that from any project.


(Dimitar Dimitrov) #5

That’s how Gradle Wrapper works when it is in the root project. Just use the right number of ../ before the command. You may also write a clever shell function to look up the directory structure until it finds gradlew, though these days I can’t be bothered to do that…

Taking your argument to the absurd extreme, why limit your debelopers to subproject roots? Why not put a wrapper in every source package directory?


(Klaus Christiansen) #6

The thing is that we are working with Eclipse.
Eclipse projects are all on same directory level. So there is not directory structure to go up in.
We have more the one root project.
Also we have libraries that some projects depends on but all. And it should be possible to build those without root projects.

We could do a CommonGradle project in SCM that has the wrapper. And possible generic build files for stylecheck, spotbugs, java.


(Daryl) #7

If I were you, and you ‘needed’ the gradle wrapper in each directory, I would just make a link to the real wrapper in each directory ( ln -s …/gradlew.sh gradlew.sh)

However, even with eclipse, you can add the entire top level project with a wrapper, and the build ship plugin should create eacch subproject’s eclips project for you with the right reference to the wrapper, or else that should be raised as a big to the team.


(Staffan Forsell) #8

In zsh, I have something like this in my .zhsrc:

function build_gradlew() {
  if [[ -f ../gradlew ]]; then
    nice -n11 ../gradlew --parallel "$@";
  else
    nice -n11 ./gradlew --parallel "$@";
  fi
};

alias gw='build_gradlew'

This has saved me a lot of time during the last years. Just thought I would share.
The --parallel part can of course be a separate alias or in gradle.properties and the nice bit can be handled using org.gradle.priority=low in gradle.properties from 5.0+ (My proposal got implemented!, https://github.com/gradle/gradle/issues/1606)