https://gradle.com/ logo
Join Slack
Powered by
This message was deleted.
# community-support
s
This message was deleted.
a
unfortunately if multiple subprojects have the same group + name then you'll run into this issue https://github.com/gradle/gradle/issues/847
b
the project layout should be something like domain restapis1 restapis2 web1 web2 so I don't think this bug is happening
basically all projects are on root level and have a different name
a
okay, good 👍
b
I suppose I need a settings.gradle.kts in the same root level folder, correct? even though I might only be building web1 and web2
a
yes, you should always have 1 
settings.gradle.kts
in the root of your project
and then in that you can tell Gradle about the subprojects:
Copy code
include(":domain")
include(":restapis1")
include(":restapis2")
include(":web1")
include(":web2")
b
and I need include("folder") for every project in there
a
bingo
v
You should already have that. If you do not, then you probably should not do that if I suspect correctly.
b
sharing build config, how do I go about that
v
Are 
web1
and 
web2
standalone projects with own 
settings.gradle(.kts)
?
b
yes
v
Then you should never define another build that also `include`s them
Never, ever, ever
A project should only belong to exactly one project, or you really can get into strange trouble
What you are after is "composite build", where you include whole builds
So you for example could create another stand-alone build with its own settings script that defines your convention plugins
This build you then include as composite build (
includeBuild
) within 
pluginManagement { ... }
of the settings scripts of 
web1
and 
web2
Then you can use those convention plugins with the centralized build logic in those builds
b
ah, I see, would I keep that settings.gradle.kts in the root folder then?
v
Alternatively you can of course also publish your convention plugins somewhere and use them from there like other plugins
You would not have any settings script in the root folder, unless you want to also create a kind of uber-build that includes all the other builds to build them together or something similar.
b
regarding common plugins and dependencies I used
Copy code
pluginManagement {
    val kotlinVersion = "1.9.0"
    plugins {
        kotlin("kapt") version kotlinVersion
        kotlin("jvm") version kotlinVersion
        kotlin("plugin.spring") version kotlinVersion
    }
}
and
Copy code
plugins {
    kotlin("kapt")
    kotlin("jvm")
    kotlin("plugin.spring")
}

java {
    sourceCompatibility = JavaVersion.VERSION_17
}
in the previous project
where would those things go in the composite build?
v
For centralizing dependency and plugin versions, I'd recommend to use the version catalog feature instead.
b
in which file would I include that?
root settings.gradle.kts?
v
You don't have a "root settings script", do you? Where you do what, depends on your setup. You could for example have at the root level a 
libs.versions.toml
and then in the settings scripts of `web1`and 
web2
do
Copy code
dependencyResolutionManagement {
    versionCatalogs {
        create("libs") {
            from(files("../libs.versions.toml"))
        }
    }
}
to use the same version catalog in both projects
b
ok, so that block would need to be included in every part of the composite build, correct?
so web1/settings.gradle.kts, domain/settings.gradle.kts, etc
is there a way to centralize that?
from what I've seen a common buildSrc was recommended for doing that, but that won't work with 2 composite builds I guess
v
You need the block where you want to use the version catalog. If you want to centralize the config, you can create a convention plugin that does this config, and then apply that convention plugin to the relevant projects. A "common buildSrc" is not something that exists. "buildSrc" is always local to one specific build and also cannot provide settings plugins which you would need for that configuration. But a convention plugin in an included build like I mentioned above can provide settings plugins and can be in included in all relevant builds.
b
thank you very much, I'll take a look 🙂
👌 1
5 Views
Open in Slack
PreviousNext
Powered by