Enforce lock constraints using shared platform #557
Conversation
Generate changelog in
|
| conf.setVisible(false); | ||
| }); | ||
|
|
||
| ProjectDependency locksDependency = |
There was a problem hiding this comment.
why do we create a self dependency?
There was a problem hiding this comment.
it's not actually "self" but pointing to a particular configuration (indirectly).
This is to pick up the locks configuration which is defined in the root project.
|
|
||
| ProjectDependency locksDependency = | ||
| (ProjectDependency) project.getDependencies().create(project); | ||
| locksDependency.capabilities(moduleDependencyCapabilitiesHandler -> |
There was a problem hiding this comment.
is this necessary given that we already have configured the configuration?
There was a problem hiding this comment.
yes - we will resolve multiple variants of the same project (root project) so if they don't have different (i.e. explicit and different) capabilities, they will conflict.
There was a problem hiding this comment.
oh right and you can't depend on an explicit capability just with attributes, you need to specify the capability.
If anything, we might not need to specify the attribute directly, but it's a bit more clear this way I think.
| conf.setCanBeConsumed(true); | ||
| conf.setVisible(false); | ||
|
|
||
| // Note: don't add constraints to the ConstraintHandler, only call `create` / `platform` on it. |
There was a problem hiding this comment.
What do you mean here? could you explain why?
There was a problem hiding this comment.
This was there before and mostly just meant the function accepting the ConstraintHandler doesn't call add on it, only create.
It's a bit confusing though so I'm gonna instead make up an interface that can only create, and pass that in.
| NamedDomainObjectProvider<Configuration> rootConfiguration = project.getConfigurations() | ||
| .register(ROOT_CONFIGURATION_NAME, conf -> { | ||
| conf.setCanBeResolved(false); | ||
| conf.setCanBeConsumed(false); |
There was a problem hiding this comment.
not setting this was an oversight, now fixed
|
👍 go go go |
|
Released 1.26.0 |
Fix versions-props plugin regression from #557 (1.26.0) in some circumstances
Before this PR
Creating lots of constraints into every single configuration being resolved (even though technically only once per project, after which they get inherited by all configurations).
This can lead to super large build scans (300MB for a large internal monorepo) where constraints are needlessly duplicated.
After this PR
==COMMIT_MSG==
Manage lock file constraints using a single platform, reducing the number of constraints that have to be created.
This works in a similar way to Java Platform Plugin. We can't just use that plugin directly, as it makes too many assumptions about the structure of the build where it's applied (e.g. needs its own project that isn't otherwise a java project, to hold the platform) that we can't make in GCV.
==COMMIT_MSG==
Possible downsides?