This message was deleted.

Not really. You can use things like

subprojects { ... }

in the root project to cross-configure the subprojects, but that is discouraged bad practice. You should use convention plugins for example in

buildSrc

or an included build for example implemented as precompiled script plugin to centralize build logic and and apply those in the projects where you want their effect to be present.

You can (but probably shouldn't) make Gradle work that way, and many projects do. It makes Gradle work more similarly to Maven, where 'child' projects inherit from 'parents'. Does the current config in your project use

subprojects {}

and

allprojects{}

? The modern Gradle way is to use 'convention plugins', which is basically equivalent to moving the `allprojects {}`/`subprojects{}` configuration into custom plugins, which can be applied to each subproject on demand. This is a big improvement, because the config can be refined and only applied to subprojects as required. It's possible to keep using `subprojects {}`/`allprojects {}`, so it really depends on how deep you want to (or are able to!) dive into Gradle

Thanks for the quick reply. As for the bump from 6.8 -> 8.5, I'm really taking on the approach of re-writing things, especially since we'll likely move to the plugin model. Currently I'm just trying to get my feet wet a little first. I did see that

subprojects { ... }

is considered bad practice but have tried it just to make it work but it isn't - at least for me. Also, I'm not using

allprojects {}

. I am seeing some rather strange "behaviour" and it could be based on my current folder structure (one that has been successfully working in 6.8) but wanted to quickly as if using the buildSrc project is the way to share configurations (assuming no plugins for now) or can I avoid that and just use a setting.gradle and build.gradle in the root and then build.gradle in the subproject (as we're currently doing it in 6.8)?

As we said, you should be able to use the same logic as in 6.8, it's just discouraged bad practice. If it does not work you should probably tell us what error you concretely have.

As a simple example, I have the following in the build.gradle in my root folder just to do a little testing and it produces the following output. settings.gradle

rootProject.name = 'isg-core-platform'

include 'shared:serialization:csv'

build.gradle

subprojects {
    apply plugin: "application"
    println(project.name + ":" + System.getenv("GRADLE_USER_HOME"))
    repositories {
        mavenCentral()
...

build output:

> Configure project :
shared:null
serialization:null
csv:null

As you can see it sees the nested folders as projects too - I don't recall this with our previous build. I also see this in my IDE:

Not sure what you are complaining about

yup, according to Gradle

include 'shared:serialization:csv'

actually adds

shared

and

shared/serialization

and

shared/serialization/csv

as subprojects, and so the

subprojects {}

block is going to add the

application

plugin to each directory

Which is not different in 6.8

LOL...my expectation is that only "csv" would show up as the project as the nesting; shared and serialization aren't projects. Perhaps my expectations are incorrect but I also don't see this behaviour in our current project - but I will review to be sure. As for my current problem/error, it seems as though the configuration for the subprojects is functioning as I expect it because when I add a dependency to the subproject it fails as it can't see the repository, despite being setup in the subprojects block. Subproject build.gradle

dependencies {
    implementation("com.fasterxml.jackson.dataformat:jackson-dataformat-csv")
}

Output:

LOL...my expectation is that only "csv" would show up as the project as the nesting; shared and serialization aren't projects. Perhaps my expectations are incorrect but I also don't see this behaviour in our current project - but I will review to be sure.

Then just do

include("csv")

and then set the project dir to the path to the project. But as I said, this was always like that.

it seems as though the configuration for the subprojects is functioning as I expect it because when I add a dependency to the subproject it fails as it can't see the repository

The problem is probably more that you do not have a version for the dependency

Yeah, I thought that too but again, this has been taken directly from a working build so I assumed it would figure it out...maybe it is expecting a BOM and I haven't gotten there yet...let me confirm by adding a version. Thanks.

I don't think so. Even in way older versions, you did not automatically configure subprojects or similar, only if you do it explicitly. If you have proof of the opposite, show me please. :-)

Will do if I find anything - my suspicion, especially based on your expertise, is that I'm misinterpreting things :)