I have a composite build consisting of multiple projects A+B+C, while A provides some plugins to B and C and is therefore included. It’s pretty much used as a replacement for buildSrc in B and C. A needs to use Gradle 5.0 RC1 for some reasons, while B and C do fine with 4.10. When executing gradlew build in A 5.10 is used as expected because of gradle-wrapper.properties. The problem is that when executing the same in B or C the build fails with compilation errors, because Gradle 4.10 is used and doesn’t provide the necessary API yet.
Included builds do not share any configuration with the composite build, or the other included builds. Each included build is configured and executed in isolation.
That statement doesn’t hold for the wrapper? So, am I expected to always update the wrapper to a compatible version in all projects that might include some other project? I there some way some included project could tell me about who includes it? I don’t see any.
I think I’ve read somewhere that only one and the same wrapper is used, like with multi-project builds(?), but can not find it anymore and would therefore ask for some clarification.
Are there any best practices how to deal with this situation? Sounds like it would be easier to not use the wrapper at all for those projects, but maintain a system wide Gradle installation instead? Or is there some way to invoke the build in one including project in a way such that all included projects are build with there configured wrapper without the need to do so manually?
Have a similar need, and therefore a similar question! @ams_tschoening, were you able to make any progress on this front? Have there been any other developments I should look into?
I’m not aware of anything and what I did to work around this problem was setting up a local IVY-repo to contain most of my deployments and make projects depend an that instead of using a composite build. In my case project A was providing Java-based plugins to make building, deploying etc. other projects easier and some of these plugins are not implemented in Java anymore at all, but using Groovy plugin-scripts instead. Those are then linked using svn:externals into consuming projects.
Don’t like these approaches too much as well, but using composite builds currently doesn’t seem to be well thought when it comes to upgrading the individual Gradle-wrappers of projects and stuff like that: