The aggregate’s API is the set of resources, topics in this case, that the aggregate is exposing to the rest of the organisation. Serves in other aggregates can access the resource metadata via the aggregate descriptor. To enable this, the api needs to be published somewhere!

Note: The IngestionAggregateDescriptor added to the services module should not be published. The servies jar should be private to the repository. If the ingestion aggregate is accessed by more than one Creek aggregate, then the IngestionAggregateDescriptor should be declared in a shared location and packaged in its own jar file.

How and where an organisation publishes jars will vary, so configuring the publishing is outside the scope of this tutorial. However, Creek doesn’t leave you completely stranded either.

Publishing to GitHub packages

The aggregate template, and hence the completed tutorial available on GitHub, comes pre-configured to publish the api module to GitHub packages, which provides a Maven repository where jars can be published.

Publishing is configured in the buildSrc/src/main/kotlin/publishing-convention.gradle.kts file. You’ll notice a ChangeMe comment in there, encouraging users to think about where their api jar should be published.

publishing {
    repositories {
        // ChangeMe: will publish to GitHub package:
        // update to publish jars to your artefact store, as required
        maven {
            name = "GitHubPackages"
            url = uri("https://maven.pkg.github.com/creek-service/${rootProject.name}")
            credentials {
                username = System.getenv("GITHUB_ACTOR")
                password = System.getenv("GITHUB_TOKEN")
            }
        }
    }

    publications {
        create<MavenPublication>("mavenJava") {
            from(components["java"])

            artifactId = "${rootProject.name}-${project.name}"
        }
    }
}

The published api can be viewed in GitHub alongside the service’s docker container.

Are GitHub packages right for your organisation?

At the time of writing GitHub packages aren’t meant as a way of publishing public artifacts, (though there is a workaround), but they are perfect for sharing artifacts within an organisation. That said, if your organisation already has a standard way of sharing Java artifacts, the api jar should be published there, ready for others to download and use.

Updated: