This message was deleted.

You can set the version (and group) for the whole project by creating

gradle.properties

in the root project directory and adding

group=my.project.group
version=1.2.3-XYZ

There are other ways of setting these values, but that's the most basic. The artifact ID will be set automatically using the name of the subproject. I mention it because it's best not to override this - it can cause problems with resolving dependencies between subprojects. The description can also be set per subproject, and Gradle will automatically use it in the POM

// ./some-subproject/build.gradle.kts

description = "I'm some-subproject and I do <stuff>"

That covers the basics...

As one task, though I've never used Sonatype before (with Maven or Gradle). I.e., they get published as separate artifacts under the same group, but they are published on the same cadence with the same version numbers. E.g., with Immutables,

org.immutables:value

,

org.immutables:value-annotations

, etc., get released at the same time and with the same version number. I noticed that Immutables (which uses Maven) puts most of the publishing information in the root POM. It seems like if the information was put in the conventions plugin (which was my first thought on how to do it), the result would be one standalone POM file for each module with (mostly) the same publishing information--though that info would be defined once in the conventions plugin. Though I don't know what the implications of having standalone POMs would be w.r.t. staging and publishing a release on Sonatype, vs. what Immutables does with its root POM.

If you run a task without a leading

:

or subproject path (e.g.

:some-subproject:task

then Gradle will run all matching tasks in the subprojects, so you'd only have to run

./gradlew publishToMavenLocal

(or an equivalent) https://docs.gradle.org/8.5/userguide/command_line_interface.html#executing_tasks_in_multi_project_builds - would that suite you? :)

From Gradle's end, I think it should be fine as long

./gradlew publish

works as intended. I probably would want to key off of a Github release to stage a release in OSSRH (see the GitHub workflow in https://docs.github.com/en/actions/publishing-packages/publishing-java-packages-with-gradle#publishing-packages-to-the-maven-central-repository). The one open question is how the POM structure matters after artifacts are staged in OSSRH: what are the implication of pushing a hierarchical POM structure (like what Immutables has) to OSSRH, vs. pushing a bunch of standalone POMs to OSSRH.

No technical implication I'm aware of. The big difference is, that Maven mixes build time information with runtime information. If you for example look at a pom of a published Maven project, your also see all the plugins that were used and configured to build that project which is totally irrelevant at usage time. So in Maven this hierarchical structure helps to just define things once and then it is also published like that. If you would subsequently modify that parent pom after publishing, it would help to just change one location, but if something is published it should not be changed anyway ever. So there is no implication I'm aware of with spreading out the information except maybe for a human that reads it. With Gradle the information you need to build the project (the build scripts) is properly separated from the information you need to consume it (the pom, ivy.xml, Gradle Module Metadata).

To close the loop on this one: In a multi-module build,

./gradlew publish

will create a single staging repository in OSSRH with all the modules (as opposed to a separate staging repository for each module). That's the one remaining question I had, in part because these modules have dependencies between them. Here are the contents of `io.github.mikewacker.drift.publish-conventions.gradle.kts`:

plugins {
    java
    `maven-publish`
    signing
}

java {
    withSourcesJar()
    withJavadocJar()
}

tasks.javadoc {
    (options as StandardJavadocDocletOptions).addBooleanOption("Werror", true)
}

group = "io.github.mikewacker.drift"
version = "0.2.0-SNAPSHOT"

publishing {
    publications {
        create<MavenPublication>("mavenJava") {
            from(components["java"])
            versionMapping {
                usage("java-api") {
                    fromResolutionOf("runtimeClasspath")
                }
                usage("java-runtime") {
                    fromResolutionResult()
                }
            }
            pom {
                url = "<https://github.com/mikewacker/drift>"
                licenses {
                    license {
                        name = "MIT License"
                        url = "<https://opensource.org/license/mit/>"
                    }
                }
                developers {
                    developer {
                        id = "mikewacker"
                        name = "Mike Wacker"
                        email = "<mailto:11431865+mikewacker@users.noreply.github.com|11431865+mikewacker@users.noreply.github.com>"
                        url = "<https://github.com/mikewacker>"
                    }
                }
                scm {
                    connection = "scm:git:<git://github.com/mikewacker/drift.git>"
                    developerConnection = "scm:git:<ssh://github.com>:mikewacker/drift.git"
                    url = "<https://github.com/mikewacker/drift/tree/main>"
                }
            }
        }
    }
    repositories {
        maven {
            name = "Ossrh"
            url = uri("<https://s01.oss.sonatype.org/service/local/staging/deploy/maven2/>")
            credentials {
                val ossrhUsername: String? by project
                val ossrhToken: String? by project
                username = ossrhUsername
                password = ossrhToken
            }
        }
    }
}

signing {
    val signingKeyId: String? by project
    val signingKey: String? by project
    val signingPassword: String? by project
    useInMemoryPgpKeys(signingKeyId, signingKey, signingPassword)
    sign(publishing.publications["mavenJava"])
}

And then each published module would also have a snippet like this:

publishing {
    publications.named<MavenPublication>("mavenJava") {
        pom {
            name = "Drift"
            description = "Lightweight, all-in-one library to rapidly prototype a JSON API."
        }
    }
}

A few notes: • I also have a GitHub workflow that runs

./gradlew publish

when I create a release in GitHub. • I'm not sure what the difference is between `.set()`/`=

and

.convention()`, but using

=

works fine for me. (But, I don't have any values that I need to "override"; everything is either set once in the conventions plugin or set once in the module build file.) • Having a separate convention plugins in

buildSrc

for Java conventions and publishing conventions is beneficial. E.g., I have an

example

module; I still want to apply my Java conventions there, but I don't want to publish it or enable the strict JavaDoc rules that I used for published modules [

(options as StandardJavadocDocletOptions).addBooleanOption("Werror", true)

].

`.set()`/`=` to

"foo"

=>

"foo"

`.set()`/`=` to

"bar"

=>

"bar"

`.set()`/`=` to

null

=> unset

.convention()

to

"foo"

=>

"foo"

.set()/=

to

"bar"

=>

"bar"

.set()/=

to

null

=>

"foo"