is there an example of self-includes? ie using includeBuild(".")
1 Like
How would you expect that to behave?
From the documentation:-
By default, substitutions are not registered for the main build. To make the (sub)projects of the main build addressable by ${project.group}:${project.name} , you can tell Gradle to treat the main build like an included build by self-including it: includeBuild(".") .
So does this mean that i can replace dependency configurations like:-
subA/build.gradle.kts
dependencies {
api(project(":subB"))
}
with
subA/build.gradle.kts
dependencies {
api(“group”, “subB”)
}
?
Ah, thanks, wasn’t aware of that sentence and never have seen that.
But yes, I would interpret it exactly like you.
It would be nice if their was a multi-project example using a self-include. I wasn’t quite getting the expected behaviour when I tried this a few weeks ago. I might get the chance to try again later this week and detail the error.
Where I’m coming from on this, is that I’ve got a large multi-project build originally in maven which has been converted over to gradle.
One of the subprojects is a plugin, which itself has dependencies on some of the other sub projects. However, a number of the other subprojects depend on the plugin. (Their isn’t any circular dependency here though). Maven deals with this quite well.
However, with gradle, we have to do two sets of runs, the first run publishes the plugin to maven local so that the plugin references can find it on on subsequent runs.
At this stage we don’t necessarily want to restructure the project into separate builds to deal with this.
I was intrigued by self-includes as it looked like it might give us behaviour similar to that of maven wrt to looking up sibling dependencies.
I would be interested in your thoughts.
For getting a sample into the official docs, you should post a feature request on GitHub and ask for it, but I’m not sure it will be done as it is probably a rare use-case, but doesn’t hurt to ask for it / suggest it either.
For getting my thoughts, I must confess I wasn’t able to fully follow.
Maybe you could throw together an MCVE that showcases the use-case?
As far as I understood the self-import will only allow to depend on projects using coordinates and that’s it, but it might as well have other consequences, I just don’t know.
With “plugin” you mean a Gradle plugin? Or some other kind of plugin?
If you mean a Gradle plugin that you want to use in the same build,
I think you indeed have to split your build into multiple that you combine via composite builds.
This can still be all in the same repository and files staying where they are.
You will just structure the build a bit differently, for example having a build with the common components and a build with the plugin and then using composite builds to wire all together in the main build.
Yes, I meant gradle plugin.
thanks