Library

A [library] project compiles sources, runs tests, and packages a plain JAR with no embedded classpath manifest. It is designed to be consumed as a dependency by other projects or published to a Maven repository.

Minimal configuration

[library]
name    = "string-utils"
version = "0.1.0"

Build output

Building string-utils v0.1.0
  Resolve deps    2 JAR(s)
  Compile         3 source file(s)
  Tests           ✔ 8 tests successful
  Package         string-utils-0.1.0.jar
  Done            target/string-utils-0.1.0.jar

The JAR contains only the compiled classes and resources. No Class-Path or Main-Class manifest entry is written — consumers are responsible for assembling their own classpath.

Full configuration reference

[library]
name    = "string-utils"
version = "0.1.0"
groupId = "com.example"  # required for curie publish

# Java version passed to javac --release (default: 21)
[java]
releaseVersion = "21"

# JUnit Platform Console Standalone version (workspace-inheritable)
[test]
junitPlatformVersion = "6.0.3"

# kotlinc + kotlin-stdlib (only needed when .kt sources are present)
[kotlin]
version = "2.1.21"

# Production dependencies (placed on the compile and runtime classpath)
[dependencies]
"com.google.guava:guava" = "33.4.8-jre"

# Test-only dependencies
[test-dependencies]
"org.junit.jupiter:junit-jupiter" = "6.0.3"
"org.assertj:assertj-core"        = "3.26.0"

# BOMs to import for version management
[bom-imports]
"com.google.guava:guava-bom" = "33.4.8-jre"

[test-bom-imports]
"org.junit:junit-bom" = "5.11.0"

# Annotation processors run during compilation
[annotation-processors]
"org.projectlombok:lombok" = "1.18.32"

[test-annotation-processors]
"com.example:test-proc" = "1.0.0"

# Additional Maven repositories (Maven Central is always included)
[[repositories]]
id  = "my-nexus"
url = "https://nexus.example.com/repository/releases/"

# Publishing to a Maven repository
[publish]
repository  = "my-nexus"
sign        = true
description = "String utility library"
homepage    = "https://github.com/example/string-utils"
licenses    = ["Apache-2.0"]
developers  = [{ id = "alice", name = "Alice", email = "alice@example.com" }]

Key fields

Difference from application

A library project differs from an application in three ways:

• No mainClass — libraries are not runnable, so no main-class scanning is done and the manifest contains no Main-Class or Class-Path entries.
• No [docker] section — only application projects can produce Docker images.
• No [native-image] section — GraalVM native compilation requires a main entry point.

Source layouts

Curie supports two layouts, and they can coexist in the same project:

• Flat-package — src/com.example.stringutils/StringUtils.java (dot-delimited package as directory name)
• Maven — src/main/java/com/example/stringutils/StringUtils.java

Test files (*Test.java, *Tests.java, *Spec.java) co-located in the source tree are treated as tests; a separate tests/ or src/test/java/ directory is optional for integration tests.

Publishing

Run curie publish to upload the JAR, a sources JAR, a javadoc JAR, and a generated POM to a Maven repository. The groupId field must be set. See Publishing for repository configuration and GPG signing.

Using as a workspace member

Library projects are the natural building block of a workspace. A sibling application can depend on a library using [workspace-dependencies]:

[application]
name    = "my-cli"
version = "0.1.0"

[workspace-dependencies]
"string-utils" = ""

Curie resolves workspace members by name, compiles them in topological order, and places the sibling JAR on the application's classpath. See Workspaces for the full workspace model.