I have multiple projects managed as composite builds and especially one providing different basic plugins I want to use in all other builds, so all other builds depend on that plugin-project. From my understanding, in case of a composite build all included builds use the same version of Gradle, that one used by the parent project. Recently I needed to upgrade Gradle and started with the basic plugin-project included by all other projects, because I knew I needed to adopt things there, which I didn’t need to in all other projects. Upgrading that individual project was easy, but the changes I made made it incompatible with older versions of Gradle, so building the other including projects failed afterwards.
The problem was that upgrading Gradle itself of including projects failed as well. I thought that upgrading Gradle is handled differently or special somehow, but it doesn’t seem to and part of the upgrade is building the included plugin-project providing the plugins, which fails because of the too old version of Gradle at time of upgrading. The only workaround I found was upgrading Gradle from the outer- to the innermost project, so upgrading and adopting the basic plugin-project at the last step instead of the first one.
But how do I know which other projects include that plugin-project? Sounds like I need to additionally document that anywhere? And what in case of a deeper project hierarchy and more projects including each other in a composite build?
I thought I could simply upgrade Gradle in the projects as needed, let builds in Jenkins fail and upgrade Gradle of including projects as needed afterwards. This way I would not be forced to document some project tree or such somewhere.
So, is that intended behaviour, that upgrading Gradle itself requires a fully functional build of a project? Or is there some way to not build and really only upgrade Gradle itself to build afterwards?