A reusable template for Scala libraries, with automatic Maven Central deployment.
- Everything from
SgtSwagrid/scala-config, including reasonable Scalafmt settings, CI piplines for build integrity, and some IDE config. - Automatic deployment to Maven Central using
sbt-ci-release. - Example build configuration and setup instructions.
Click 'Use this template' on GitHub, and follow the instructions to create a new repository for your library. All files herein will be copied as-is.
2. Configure build.sbt and release.sbt
Replace every placeholder with real values for your project.
The sbt settings necessary for publishing are defined by sbt-ci-release and are documented here.
| Name | Purpose | Example |
|---|---|---|
name |
Your library's name (for people). | Dog Food Finder |
normalizedName |
Your library's name (for robots). | dog-food-finder |
organization |
Your organisation's package namespace. | org.nohungrydogs |
organizationName |
Your organisation's name. | No Hungry Dogs |
organizationHomepage |
Your organisation's website. | nohungrydogs.org |
versionScheme |
What does the version number say about binary compatibility? | strict |
licenses |
The license under which your library is released. Update LICENSE.md to match. |
MIT |
scmInfo |
Your library's Git repository. | https://github.com/no-hungry-dogs/dog-food-finder |
developers |
The individual developers who contribute to your library. | SgtSwagrid |
| Name | Purpose | Example |
|---|---|---|
packagePrefix |
IntelliJ's implicit package prefix for all code files. | org.nohungrydogs |
Name of subproject (following lazy val) |
Your library's name, or the name of a particular module. | dog-food-finder |
Each subproject listed in build.sbt is published as a separate artefact on Maven (albeit under the same versioning),
which is useful if you want a modular design whereby downstream users need not include all facets of your library.
Typically in this case you'll introduce one top-level subdirectory for each subproject.
Settings are read from every .sbt file in the project root.
It doesn't matter what they are called, other than that sbt simply concatenates their contents in alphabetical order of their names.
A division between build information and publishing information is introduced for convenience.
- Create an account on Maven Central to enable publishing, if you don't already have one.
- Register your namespace (e.g.
org.nohungrydogs). This should match theorganizationsetting inrelease.sbt. - Generate a user token. This will give you a username and password, which you can add as repository secrets (see step 5).
Execute the following on your local machine to generate a PGP key:
# Generate a new PGP key, making sure to remember your passphrase:
gpg --gen-key
# Expose the secret key in base64, using the public key provided by the above:
gpg --armor --export-secret-keys <PUBLIC_KEY> | base64
# Upload the public key to a keyserver:
gpg --keyserver keyserver.ubuntu.com --send-keys <PUBLIC_KEY>Add the following secrets to your repository on GitHub, to allow publishing as part of an automated workflow:
| Secret | Value |
|---|---|
SONATYPE_USERNAME |
Username from Maven user token in step 3. |
SONATYPE_PASSWORD |
Password from Maven user token in step 3. |
PGP_SECRET |
Base64-encoded PGP private key from step 4. |
PGP_PASSPHRASE |
Passphrase used when generating the PGP key in step 4. |
GH_TOKEN |
Your GitHub PAT with administrator to access your repository. |
CLAUDE_CODE_OAUTH_TOKEN |
API key from Claude for agentic workflows (optional). |
Secrets can be added from the GitHub web interface by nagivating as follows from your repository's page:
Settings → Secrets and variables → Actions
The included MIT license should be considered only as part of the template, and is not binding.
This repository is hereby released to the public domain, to be used freely.
In particular, and contra LICENSE.md, you may remove the license text from copies.
CONTRIBUTING.md is also part of the template, and does not necessarily apply to contributions to the template itself.
The most important thing to know is that many of the configuration files are automatically synced from scala-config, and should be updated there rather than here.
Check out scala-website-template for a similar template to quickly start a new full stack website in Scala.
GitHub releases are automatically published to Maven Central upon creation, using sbt-dynver.
To release version 1.2.3, go to Releases → Draft a new release, create the tag v1.2.3, and click Publish release.
Note the inclusion of v in the GitHub release name but not the resulting Maven version.