The 1.0.0-alpha1 release build failed at the publish step:

Task 'publishArchives closeAndReleaseSonatypeStagingRepository' not found in root project 'mongo-hibernate' and its subprojects.

Two distinct defects, the first of which caused the failure.

1. Both task names are passed to Gradle as a single argument

.evergreen/publish.sh assembles the task list in TASK and invokes ./gradlew ... "${TASK}". The quotes make the two release task names one argv element, so Gradle looks for a single task literally named publishArchives closeAndReleaseSonatypeStagingRepository. The quoting was introduced in f7d8f7c; before that ${TASK} was unquoted and word splitting produced two arguments. Snapshot publishing was unaffected because publishSnapshots is one word, so the regression went unnoticed until the first release attempt after that commit.

Fix: hold the task list in a bash array and expand it with "${TASKS[@]}".

2. The publish lifecycle tasks cover only the root project

Since the last release the build became multi-module: mongodb-hibernate-spring-boot-autoconfigure and mongodb-hibernate-spring-boot-starter, both of which apply the mongo-hibernate-publish convention plugin and define a maven publication.

publishArchives and publishSnapshots in the root build.gradle.kts declare dependsOn(tasks.named("publishToSonatype")) and dependsOn(tasks.named("publishAllPublicationsToLocalBuildRepository")). Both resolve to the root project's tasks only. Confirmed with ./gradlew :publishToSonatype --dry-run, whose task graph contains no subproject tasks.

Consequence: with defect 1 fixed, the release would upload mongodb-hibernate alone. The two Spring Boot modules would be compiled and signed but never uploaded, and the build would still succeed. Invoking publishToSonatype unqualified does reach every project, because Gradle name-matches the task across all projects, which is what masks the difference during local testing.

Fix: have both lifecycle tasks additionally depend on the subprojects' equivalents, using lazy task paths so subproject evaluation order does not matter.

3. The starter module publishes no sources or javadoc jar

mongodb-hibernate-spring-boot-starter applies plain java-library rather than the mongo-hibernate-java convention plugin, so it never calls withSourcesJar() / withJavadocJar(). Publishing it to the local build repository produces only the main jar and the POM, whereas the other two modules also produce -sources.jar and -javadoc.jar. Maven Central requires both for every released artifact, so closeSonatypeStagingRepository would fail the validation step after the upload succeeded.

Fix: produce both jars from the mongo-hibernate-publish convention plugin rather than from mongo-hibernate-java, since the requirement follows from publishing a module rather than from how the module is compiled. Both jars are empty for the starter because it has no source code, which is also true of Spring Boot's own starters.

Both Spring Boot modules are in scope for 1.0.0-alpha1.