Execute a disparate Gradle build which uses a Gradle wrapper

Help/Discuss
1

Hi Gradle community.

I’ve an odd build situation for which a multi-project build cannot be used: I’ve two separate code bases A and B and B needs to invoke a Gradle task in A and I can only change the build for B. I see that this can be achieved with the following code

task taskForA(type: GradleBuild) { buildFile = '/projects/A/build.gradle tasks = ['clean', 'build'] }

unfortunately A uses a customized Gradle wrapper and I’m wondering how can I modify taskForA to use the Gradle wrapper for A rather than running gradle?

Many thanks.

2

Maybe the key to this is to override a value in StartParameter?

3

StartParamter allows me to redefine the parameters passed to gradle so it doesn’t seem to allow me to alter what gradle executable gets called

4

The GradleBuild task expects to run the other build with the same version of Gradle (it runs it with an internal API).

I think what you’re looking for is something we just started working on called Composite Builds. You can define a set of projects that need to be built together and have dependencies across the different builds. I’m assuming you need artifacts from A in order for B to compile.

For now, I think you’ll have to resort to calling gradlew in A from an Exec task and wiring the builds together manually.

5

Thanks for your reply, Sterling.

Good to know that GradleBuild executes a build with its running instance of Gradle.

Composite Builds definitely sounds like the perfect solution – unfortunately I’ve got to stick to the Gradle version bundled with each repo. As you’ve mentioned B does depend on artifacts from A to compile.

My dirty solution for now is to run gradlew via exec - as you’ve already suggested, thanks for that, at least I know I’m not doing something completely terrible.

I’m also having partial success with the whole chaining of GradleConnector -> ProjectConnection -> BuildLauncher although when the build of A is triggered from B some of A’s tasks fail because a property file cannot be found. So I’m looking to find a way to tell A about the unresolved property file when triggering the build from B. If I get that then I’ll have resolved the issue. Any idea how B can tell A about the location of a particular property file?

Thanks again for your response!!

6

Composite builds is sort of like another build itself, which can have its own newer version, so it works with older versions of Gradle.

Is the property file a gradle.properties file or something else? If it’s something that the build reads, it might be there’s a problem in A’s build. e.g., if A did something like:

def propertiesFile = new File("path/to/my.properties")
// read propertiesFile

This would mostly work. Except, A’s build would be sensitive to the working directory of the JVM that runs the build.

7

Thanks for the suggestion, Sterling. I found the root cause which had to do with some black magic that was going on with the Gradle jar file. Thanks for your help!