This message was deleted.

"assemble" is not a phase, this is not Maven. 😉 It is just a lifecycle task that allows you to conveniently trigger a list of other tasks. It is nothing you depend on using a

project(...)

dependency. Read here for information on how to properly use results from one project in the other: https://docs.gradle.org/current/userguide/cross_project_publications.html

@Vampire if you have the time, could you please verify my current setup: So in the spring boot module, I added this:

// new configuration called bootJarArtifacts that is consumable
configurations {
    bootJarArtifacts {
        canBeConsumed = true
        canBeResolved = false
    }
}

// make an artifact available in the "bootJarArtifacts" configuration
// the artifact that is made available is the output of the bootJar task (provided by spring boot plugin)
artifacts {
    bootJarArtifacts(bootJar)
}

This was on the producing side, now for the consuming side (here I am less confident I am doing it right)

// define resolvable configuration for installer resources
configurations {
    installerResources {
        canBeConsumed = false
        canBeResolved = true
    }
}

// In the new installerResources configuration, depend on the web-application project artifacts in the custom configuration "bootJarArtifacts"
dependencies {
    installerResources(project(path: ":web-application", configuration: 'bootJarArtifacts'))
}

// a task that retrieves the dependencies defined in the installerResources configuration and copies them to
// the correct folder in src/main/dist/lib
def addSpringBootJarToDist = tasks.register("addSpringBootJarToDist");
addSpringBootJarToDist.configure() {

    group = 'Build'
    description = 'Adds the spring boot jar to the lib folder of the dist.'
    doFirst {
        // we currently publish only one artifact, so we depend on this --> getSingleFile
        def bootJar = configurations.named("installerResources").get().getSingleFile()
        copy {
            from bootJar
            into "$project.projectDir/src/main/dist/lib"
            eachFile { details ->
                details.setRelativePath new RelativePath(true, "application.jar")
            }
        }
    }
}

Argh, no, don't write a task that copies the file into

src/main/dist

.

src/main/dist

is for checked in things to copy into the distribution, not for build artifacts. Configure the distribution instead. Something like (untested):

distributions {
    main {
        contents {
            from(configurations.installerResources)
            into('lib')
        }
    }
}

Aaaaah, makes more sense indeed

Right there in the docs: https://docs.gradle.org/current/userguide/userguide_single.html#sec:distribution_contents

yeah, I use the distribution plugin with the contents and that is indeed documented, but that you can also use it together directly with custom configurations is something you don’t see in the examples

Agreed. They cannot documente each variance in every place, or the docs would not be usable anymore. 😄 But for that you have the JavaDoc or the IDE telling you that you are actually configuring a

CopySpec

and so can use anything also usable there. 🙂

Totally agree I look at it too much as “configuring” and forget too often that it is a groovy file

That's generally good way to look at it. Build scripts themselves should be as declarative as possible to be idiomatic and any logic is better suited in custom plugins or tasks which are very cheap with Gradle. 🙂 But sometimes having a full coding language at the fingertips is indeed handy. Though I greatly prefer Kotlin DSL, much safer through static typing and much better IDE support. 🙂