Build-logic. Why dependencies in build-logic is resolved by repos in pluginManament

Help/Discuss
1

Description of project
There is a project with build-logic as included build

project:
- build-logic:
-   plugin
-     src>main>kotlin>my-conv.gradle.kts
-     build.gradle.kts
-   settings.gradle.kts < - with dependencyResolutionManagement{ repositories { maven1}}
- product
-   src>main>kotlin>….
-   build.gradle.kts  ← with my-conv plugin from build-logic
- settings.gradle.kts < - with pluginManagement {repositories { maven2}}

When the project is builded the dependencies form build-logic > build.gradle.kts is resolved by maven2 from pluginManagement in root.

The expected place to use repository from build.gradle.tks in build-logic because it required to build this convention plugin.

Could anybody explane?

2

That’s just normal.

The build-logic project is a separate stand-alone build that “happens” to be built before your composite build that includes it. When building that build, the repositories declare in its build script or settings script are used to resolve the dependencies.

But at the time the plugin is applied to your including build, those repositories are irrelevant, just like if you would apply the plugin form a remote repository pre-built. So the dependencies are resolved using the plugin repositories of the including build just as usual.

3

in pluginManagement.ropository the artifactory://rop-maven… is used. to solve artifactory the com.google.cloud.artifactregistry.gradle-plugin should be applyed.
acording the plugin doc it possible using the buildscript{ repositoryies{maven} dependencies {classpath()}} and it works for dependencyResolutionManagement {}

but how to apply it before pluginManagement to resolve this url with artifactory://

4

when the build-logic is builded one ropository is used and it used dependencies from this repo and if when the plugin is applyed reposities are used from pluginManagement is looks like inconsistency.

for instance in build-logic we use repo1 and repo2 but in root pluginManagement is used repo3 where no libs required for build-logic . and it will faile the build

5

to clarify the problem

build-logic
  build.gradle.kts
    dependencies{ implementation(“com.my:some-plugin:0.0.1”)

when build-logic project is builded no problem because it use a repositories from build-logic > settings.gradle.kts > dependencyResolutionManagement

When build-logis is added as includedBuild(“./build-logic”) in root porject the build of root is failed because no repository in pluginMangement where com.my:some-plugin:0.0.1 is present.

How it can be solved?

6

The similar discasion where found Different behaivor between buildSrc and include build build-logic - #4 by Vampire and Gradle isn't serching the right repository for plugins - #3 by Vampire

It looks like only the following solution is possible:

  1. Add the repository from build-logic in the pluginManagement { repositories { … } } to root.
  2. Replace build-logic (includedBuild) to use buildSrc.
    buildSrc is a project that is built always before the main build and put to the classpath of all build scripts by being in a parent class loader of the class loader for the build scripts.
7

but how to apply it before pluginManagement to resolve this url with artifactory://

Such things you should ask those folks, not in a Gradle forum.
But I had a look for you, that plugin also handles plugin management repositories if apply it in the settings script, not the build script:

This should probably work as long as you do not need to resolve settings plugins from that repository, as the plugin can only work when the settings plugin is executed so after the settings plugins were resolved.

when the build-logic is builded one ropository is used and it used dependencies from this repo and if when the plugin is applyed reposities are used from pluginManagement is looks like inconsistency.

And yet, doing it differently would be the inconsistency.
Repositories used for building are never the repositories used for consumption as I explained above already.
This is the same for dependencies as well as plugins.
The consumer always controls where transitive dependencies are resolved from.

To maybe better understand it, keep in mind the original use-case of included builds.
You have a dependency on x:y:1, then you want to do some change in that library and test it right away in your project, so include the library build, do the development, then you can release a new version of that library and remove the build inclusion again.
Nowadays, included builds are used for more use-cases, but that was the original one.

for instance in build-logic we use repo1 and repo2 but in root pluginManagement is used repo3 where no libs required for build-logic . and it will faile the build

Exactly, and this is consistent.
If you build build-logic separately and publish it to some repository, then consume that published version, you also have to define proper repositories where the dependencies are resolved from.
The consuming build always controls the repositories, even if the consumed artifact comes from an included build.

to clarify the problem

No need to clarify, I already understood it properly in your first message and explained it to you.

How it can be solved?

Define the repositories in the consuming build.

  1. Add the repository from build-logic in the pluginManagement { repositories { … } } to root.

Exactly

  1. Replace build-logic (includedBuild) to use buildSrc

Sure, buildSrc is always a bit special, so that would work also, if you are ok with the subtle differences and problems it brings, like buildSrc dependencies then overriding any version you otherwise have in your build script classpaths, no conflict resolution or even detection there, not able to provide settings plugins in buildSrc, …

8

Thanks a lot. Now it is clear for me.

1 Like