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):
[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:
[[credentials]] repo_id = "internal-nexus" username = "${NEXUS_USER}" password = "${NEXUS_TOKEN}"
Running a publish
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:
Dry-run 20 file(s) would be uploaded
Flags
| Flag | Effect |
|---|---|
--dry-run | Build all artifacts but do not PUT anything |
--no-sign | Skip GPG signatures (overrides [publish] sign = true) |
--no-javadoc | Skip 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:
- The artifact itself
.sha1,.sha256,.sha512checksum sidecars.ascGPG detached signature (when signing is enabled)
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:
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)