Composite build causes dependencies to be ignored

[stewartbryson]

I'm not actually sure if this is fixable, but I thought I would raise it. I'm also not sure of the value of resolving it.

Any dependencies mentioned in the includeBuild closure in the settings.gradle file are ignored. Arguably, if I am using composite builds, then to a certain degree I should be aware of new releases with those projects. However, in a large organization building microservices with lots of composite build dependencies, this gap could be a headache.

Obviously, when using the CLI option of include-build this is not an issue. We can simply run dependencyUpdates without that flag to see dependency updates. But, when using includeBuild, I have to comment out that closure in the settings.gradle file to see dependency updates.

I'm not sure if this plugin should have a strategy for the new source dependency option... but that is simply an extension of composite builds. So might be worth considering.

Thanks for a great plugin.

[ben-manes]

That's an interesting observation. This is something that I'm not familiar with and wouldn't have the time to investigate, but happy to accept a PR if someone does.

We currently iterate through all projects, but that's only for that build. A composite sounds like it calls out to other builds and isn't programmatically available (see Gradle#includedBuilds). Maybe this can be propagated by applying the plugin in buildSrc, though again I'm not too familiar with that. From a very cursory look, I don't think we could get a composite report easily but I may have overlooked something.

[stewartbryson]

My understanding is that buildSrc has been reworked to use the Composite Build functionality. This could make this issue and #284 solved with the same code.

Let me take a look at the code @ben-manes and see if I can figure out how it would be done.

[Vampire]

No, buildSrc is not yet a composite build. It is still its own thing with special handling. With Gradle 8.0 it will be even more similar to an included build, but still separate.

But I think @ben-manes did misinterpret the issue here. What I read is, that @stewartbryson uses composite builds the "originally intended way", which is to have a binary dependency on some library, but then replace that with an included build for developing both in parallel. And there he wants to know when that dependency has a newer version available, not when the dependencies within the included build have updates (which would also be nice but is a different topic).