From mobile apps to microservices, from small startups to big enterprises, Gradle helps teams build, automate and deliver better software, faster.

Gradle Community

This is indeed a drawback compared to `buildSrc` (which is “local” and only seen by the build that defines it).

There is an issue for this (feel free to upvote/comment): <https://github.com/gradle/gradle/issues/17228>

The solution for this right now is to add another “includeBuild” statement to your build that includes the other “gradle/plugins” and renames it:

```pluginManagement {
    includeBuild("gradle/plugins")
    includeBuild('../path/to/otherbuild/gradle/plugins') { name = 'otherbuild-gradle-plugins' }
}```
See also comment here: <https://github.com/gradle/gradle/issues/17228#issuecomment-844119362>

Note that this “name” is only for Gradle’s internal identification of builds and the _path_ you use to address tasks in included builds if you need to call them directly from the command line (which you usually don’t do for gradle/plugins builds).
Setting the name does not change anything about the identity of the component the build might produce (like, coordinates for dependencies).

interesting :thinking_face:
I "namespaced" my local `gradle/plugins` include instead, as I'm only running composite builds when I need them (using `./gradlew build --include-build &lt;path-to-other&gt;`
```pluginManagement {
    includeBuild ("gradle/plugins") {
        name = "my-project-gradle-plugins"
    }
} ```
this seems to work fine

If I consistently do this on all projects that use the convention, there shouldn't be any conflicts anymore.

:+1: I think that’s right. And maybe that’s what Gradle could do automatically if there is such a name conflict instead of throwing an error.