Composite build resolution issue


I’m applying the structuring-software-projectssample on my codebase.
The actual root structure is a composite-build :

  • build-logic
  • gfc-budget
  • plateformes
  • server-application

Each project is a multi-project.

I have some issue inside the gfc-budget build

A problem occurred configuring project ‘:gfc-budget:budget-enums’.
Could not resolve all artifacts for configuration ‘:gfc-budget:budget-enums:classpath’.
Could not find gfc.plateforme:plateforme-plugins:.
Required by:
project :gfc-budget:budget-enums > project :build-logic:generation-enums
Could not find cocktail.platform.db:cocktail.platform.db.gradle.plugin:.
Required by:
project :gfc-budget:budget-enums > project :build-logic:generation-enums

The settings.gradle of gfc-budget is defined as :

== Define locations for build logic ==
pluginManagement {
repositories {
// == Define locations for components ==
dependencyResolutionManagement {
} = ‘gfc-budget’

And its build.gradle

plugins {
group = “{group}.quartier.{name}”

I don’t understand the resolution process in this case.
Why resolution substitution doesn’t occured ?
Which piece of configuration am I missing ?
(I try to tweak and compare with the official sample and everything seems to work just fine)

Thank you

I’m trying to asnwer my question.
My best shot is the order declaration of the includeBuild statements
My habit is alphabetical order for dependencies and my includeBuild was in alphabetical order
But seems to me that I nee to declare all the builds in logical order

Your right, the includeBuild order matters! I found this fact in some other posts I cant remember and I can confirm from self experience.

But allow me a question out of interest:
You say you have a root project with all the others included. But you also have some projects already included inside gfc-budget?
I have a kind of similar scenario so if you might share some more of your build structure I would be glad :slight_smile:

I didn’t spend much time from January to this model so I’m a bit rusty.

  • The top structure is a Monolith (a composite build)
  • Inside this root / build, each project represents a “bounded context” (as in DDD ; a microservice ou something similar).
  • each “bounded context” can further be decomposed in smaller parts. There is multiple ways of decomposing : a smaller business unit or like in the gradle sample per layer (model, persistence, …) etc etc.

In the next months I will try to add for each context a subproject that can “launch” (a spring boot app) the context. The idea is to have a monolith for the moment but each context must be autonomous (you can use archUnit to forbid imports between contexts) and be started individually. When a context become stable I will try to extract it from the monolith