Hello, I have a bit tricky issue to solve. I have a repository using composite builds. This repository works as a technical platform and is meant to publish both libraries and gradle plugins. Within this repository we have multiple builds plugins <- Is a simple build which does not include any other. It also only pulls in external dependencies published on maven repository or similar (nothing in the same repo) core <- All libraries, include "plugins" which is used to setup streamlined subproject tooling <- Here we build general help tools, which uses logic from core and plugins, this means that we write both libraries and plugins. Most plugins gets hence transitative dependencies to "core" since on some level in the dependency graph core is used. test-system <- pulls in plugins, core and tooling Now... The issue is when I try to apply plugins written in tooling, which have transitative dependencies to "core". It seems like Gradle is not able to substitute such dependencies under plugin resolution, while the same dependencies gets substituted fine for libraries and services in the test-system. Question: What are the approach for using plugins in a larger composite build setup, with transitative dependencies to other builds? What is the recommended approach?

I'm not 100% sure whether I got the situation right, an MCVE might help greatly to show your exact situation without the chance for misunderstandings. But if I got it right, I question how this should technically ever be considered to work. If

tooling

provides Gradle plugins that are applied in the build for

core

and

core

want's to apply those plugins from

tooling

in their build, this is a chicken-and-egg situation. A dependency substitution cannot be made, because what you described - if I got it right - means that to build

core

you need the plugins in

plugins

but to build the

plugins

you need

core

but to get

core

you need

plugins

...

No sorry. Core do not use plugins from tooling. Tooling uses logic written in core and build plugins around that. So in some of those plugins pom files we can see the GAV for libraries in CORE. This works fine. The issue occurs in test-system, when it tries to apply one such plugin. It finds the plugin it gets applied, but fails on that the "transitative dependency" to some of "core"s library is defined as GAV coordinates and do not pick up any substitutions as with regular "includeBuilds" where we can state that those dependencies should be substituted to a project reference (project("librarieslib1") for instance).

If everything is setup properly, you should actually never need any manual substitution rule. Those are usually just necessary if you do evil stuff like changing the group or name on the publication from the defaults.

Sure I will work on one. But in the meantime, previously we had a setup which did not require any manual intervention, by letting each GAV, be defined as groupnameversion, And the name would be the leaf directory name. Problem with that was when we published all our artifacts, publications with the same "leaf" directory name (with leaf I mean dir1/dir2/leaf -> name would be leaf here) would clash on the consumer repo side since the jars would be named the same for example: common-1.0.0 and common-1.0.0 even though they have different groups. So now we added logic to update the artifact ID at publication and hence we need to update the composite substitution since these coordinates does not align with the default substitition behaviour.

Just name your leaf projects like the artifact should be named. You can keep the same directory structure on disk.

well sure but then the directory names will be pretty unreadable. What is the purpose for subprojects in that case? Should I remove all hierarchies and just have all subprojects on the same level and just create long uggly names? 😞 So right now we have section which can look like: platform/common platform/messaging/common platform/messaging/logic1 but you suggest that I change to platform-common platform-messaging-common platform-messaging-logic1 Is that the recommended approach?

well sure but then the directory names will be pretty unreadable.

Why? As I said, the directory names do not need to be changed.

What is the purpose for subprojects in that case?

I don't get the question. What do you mean? Subprojects bring structure.

Should I remove all hierarchies and just have all subprojects on the same level and just create long uggly names? 😞

No need to as far as project structure and directory structure are concerned, but the projects are best named like the artifact should be named.

So right now we have section which can look like:

but you suggest that I change to

I did not

Hi again. I managed to find a fix that solved all my issues. Thank you for your time. It gave me the right direction 😄