Add first-class support for included/composite builds

[LouisCAD]

Right now, included builds are treated like regular projects, which means their versions are separate from the the project that includes them.

While this is great when you want to keep the projects decoupled, it'd be great to also have the option to share the setup, the versions.properties file, and have runs of the refreshVersion task also refresh the versions from all included builds that opt-in to this behavior.

[Savrov]

Hello, you asked us (developers) to describe here use cases, where we would need that feature. So, I have a Kotlin MPP, that has multiple modules:

• common
• backend
• frontend

So, it will be great if we could update versions.properties to manage dependencies in an entire project.

[LouisCAD]

@Savrov This is already supported.

This issue is not about multi-module projects but about includedBuildssupport, which is different.

[NikkyAI]

do included builds work at all when refreshVersions is involved?
i do not need the versions.properties to be synced or shared..

when i try to run the task in the parent project i get errors like

* What went wrong:
Execution failed for task ':refreshVersions'.
> Couldn't resolve version for ModuleId(group=org.springframework, name=spring-context-indexer)

and idea gradle sync shows this:

Unable to build Kotlin project configuration

org.gradle.api.internal.tasks.DefaultTaskContainer$TaskCreationException: Could not create task ':refreshVersions'
   ---
Caused by: java.lang.IllegalStateException: Property versionsPropertiesFile not initialized yet! Has it been used after reset or before init?
	at de.fayard.refreshVersions.core.internal.ResettableDelegates$LateInit.getValue(ResettableLateInitDelegate.kt:33)
	at de.fayard.refreshVersions.core.internal.RefreshVersionsConfigHolder.getVersionsPropertiesFile(RefreshVersionsConfigHolder.kt)
	at de.fayard.refreshVersions.core.RefreshVersionsCorePlugin$apply$2.execute(RefreshVersionsCorePlugin.kt:20)
	at de.fayard.refreshVersions.core.RefreshVersionsCorePlugin$apply$2.execute(RefreshVersionsCorePlugin.kt:13)
	at org.gradle.api.internal.DefaultMutationGuard$2.execute(DefaultMutationGuard.java:44)
	at org.gradle.api.internal.DefaultMutationGuard$2.execute(DefaultMutationGuard.java:44)
	at org.gradle.configuration.internal.DefaultUserCodeApplicationContext$CurrentApplication$1.execute(DefaultUserCodeApplicationContext.java:100)
	....

on both parent and included build

i created a sample to reproduce this:
https://github.com/NikkyAI/refreshVersions/tree/main/sample-include-build
as soon as refreshVersions is loaded in both root project and included project, stuff breaks

[oblitzitate]

I saw the following articles that convinced me to prefer composite builds over buildSrc:

• Stop using Gradle buildSrc. Use composite builds instead
• How to use Composite builds as a replacement of buildSrc in Gradle

According to the articles, buildSrc is inefficient compared to composite builds so I'm definitely all for first-class support for composite builds.

[NikkyAI]

in the newest versions of gradle buildSrc is a included build, so not sure how much those articles still hold true

[NikkyAI]

dirty experiment to see if refreshVersions can automatically set up task dependencies on refreshVersions in included builds

gradle.rootProject {
    afterEvaluate {
        val task = gradle.includedBuilds.firstOrNull()?.task(":refreshVersionsDDDDsjdfhdsiuf")!!
        logger.lifecycle("task: $task")
        val ourTask = tasks.create("doStuffYouKnow")
        val dependsOn = ourTask.dependsOn
        ourTask.dependsOn(task)
        try {
            ourTask.taskDependencies.getDependencies(ourTask)
        } catch (e: Exception) {
            ourTask.setDependsOn(dependsOn)
            System.err.println("our marvellous task is not there ;) :P :D :D :D")
        }
    }
}

[NikkyAI]

sharing a single versions.properties file works right now.. but having dependencies from different projects all flatmapped into it will create issues when trying to detect unused dependencies

i would suggest to put comments on each entry:

+ ## from: server
+ ## from: api
version.kotlinx.datetime=0.1.1
##           # available=0.2.0
##           # available=0.2.1

the formatting can be whatever, but essentially
it lists the rootDir.name of the rootProject that has this dependency or some extra identifier for the buildSrc
once all of those comments are gone.. refreshVersions can assume that the entry is unused

could alos be one line

## from: server api some-lib

[NikkyAI]

we already figured out it is possible to list the included projects from the root of the repository
but for a included project there needs to be some syntax that configured it in 'agent' mode

refreshVersions {
   mainProjectPath = rootDir.parentFile
}

this would set up

versionsPropertiesFile = mainProjectPath.resolve("versions.properties")

and probably some other things i am forgetting

[LouisCAD]

I don't see how the version entry usage comments would be removed.

[Vampire]

in the newest versions of gradle buildSrc is a included build, so not sure how much those articles still hold true

This is not true. buildSrc is still a very special extra-case and not yet an included build.
With Gradle 8 there will be some further changes that make buildSrc even more similar to an included build,
but still it will not be a regular included build.

refreshVersions {
  mainProjectPath = rootDir.parentFile
}

An included build can access the parent build and its root project directory like gradle.parent?.rootProject?.rootDir, or if the top-most one is wanted, recursing gradle.parent until parent is null and then there rootProject.rootDir.

[Chuddington]

+1 to the wish of getting this feature up and running.

The scenario is being tackled at the moment is that there's a whole load of sub modules in the git repository for an android project. Whilst that's not part of what this issue aims to resolve, it does mean that there's a lot of common configuration (detekt, ktlint, sonar, jacoco...) that creates an amount of duplication.

So this is where the includeBuild clause comes in, to create plugins that can then be applied throughout the modules. Because there are implementation dependencies in the included build that are then inherently used throughout the projects, so having a single location for version declarations that are clever enough to be aware of version updates quickly via the refreshVersions plugin would be real nice.

In my mind, I'm thinking that an architectural pattern similar to how dokka has 'collector' tasks, so that can then be fed up to a top-level task that then regenerates the versions.properties and the Libs.kt file in :buildSrc.