Subsystem · publish

Publishing

curie publish uploads your library or application to any Maven 2-layout repository — Nexus, Artifactory, GitHub Packages, or a self-hosted mirror. It generates a POM, builds sources and javadoc jars, optionally GPG-signs everything, and uploads each artifact with its checksums via HTTP PUT.

Configuration

Add a [publish] table and declare the target repository. All POM-metadata fields are required at publish time (Maven Central's validation checks them):

Curie.toml
[library]
name    = "my-lib"
version = "1.0.0"
# groupId is required for publishing
groupId = "com.example"

[[repositories]]
id  = "internal-nexus"
url = "https://nexus.internal/repository/releases/"

[publish]
repository  = "internal-nexus"  # references the [[repositories]] entry above
sign        = true              # GPG-sign every artifact (default: true)
javadoc     = true              # build javadoc jar (default: true)
description = "A useful library"
homepage    = "https://github.com/example/my-lib"
licenses    = ["Apache-2.0"]
developers  = [{ id = "alice", name = "Alice", email = "alice@example.com" }]
scm         = { url = "https://github.com/example/my-lib",
                 connection = "scm:git:git@github.com:example/my-lib.git" }

Credentials

Authentication lives in ~/.curie/config.toml so credentials never touch the project tree. Use ${ENV_VAR} indirection to keep secrets out of the file itself:

~/.curie/config.toml
[[credentials]]
repo_id  = "internal-nexus"
username = "${NEXUS_USER}"
password = "${NEXUS_TOKEN}"

Running a publish

$ curie publish --project my-lib
Building my-lib v1.0.0
  Resolve deps    3 JAR(s)
  Compile         5 source file(s)
  Tests           ✔ 12 tests successful
  Package         my-lib-1.0.0.jar
  Sources jar     my-lib-1.0.0-sources.jar
  Javadoc jar     my-lib-1.0.0-javadoc.jar
  POM             my-lib-1.0.0.pom
  Signed          4 artifact(s)
  Publishing to   https://nexus.internal/repository/releases/com/example/my-lib/1.0.0
    → my-lib-1.0.0.jar  (.sha1 .sha256 .sha512 .asc)
    → my-lib-1.0.0-sources.jar  (…)
    → my-lib-1.0.0-javadoc.jar  (…)
    → my-lib-1.0.0.pom  (…)
  Uploaded        20 file(s)

Dry run

Preview the upload plan without making any network calls. Credentials are not required in dry-run mode:

$ curie publish --dry-run
  Dry-run         20 file(s) would be uploaded

Flags

FlagEffect
--dry-runBuild all artifacts but do not PUT anything
--no-signSkip GPG signatures (overrides [publish] sign = true)
--no-javadocSkip javadoc jar (overrides [publish] javadoc = true)
--repo <url>Override the target URL inline (bypasses [publish] repository)

What gets uploaded

For each artifact (.jar, -sources.jar, -javadoc.jar, .pom) Curie PUTs:

POM generation

Curie writes a complete POM 4.0.0 XML file from your Curie.toml. The [dependencies] table becomes <dependencies> with <scope>compile</scope>; BOM-managed deps have their resolved version written in. SPDX license identifiers are expanded to the canonical <name> and <url> values (Apache-2.0, MIT, BSD-3-Clause, and a dozen others are built-in).

GPG signing

When sign = true (the default), Curie shells out to gpg --detach-sign --armor. The default GPG key is used; set the GPG_KEY environment variable to select a specific key by fingerprint or email.

gpg must be on PATH. If it isn't and signing is enabled, the build fails with a clear error pointing at the --no-sign flag.

Publishing a BOM

BOM projects use the same [publish] configuration as libraries. The only difference is the upload set — there is no JAR, sources jar, or javadoc jar, so only the POM and its checksum sidecars are uploaded:

$ curie publish
Building my-platform-bom v1.0.0
  POM             my-platform-bom-1.0.0.pom
  Signed          1 artifact(s)
  Publishing to   https://nexus.internal/repository/releases/com/example/my-platform-bom/1.0.0
    → my-platform-bom-1.0.0.pom  (.sha1 .sha256 .sha512 .asc)
  Uploaded        5 file(s)