java-library-template 🎨

TLDR: Java Library GitHub Template Repository

• Introducing 'java-library-template' in 60s - YouTube
• https://thriving.dev/blog/java-library-development-get-started-quickly-with-java-library-template

Features

• 🥷 One-click automated initial project migration workflow (GitHub Action)
• Java 21 (corretto) 🤝 Gradle Kotlin DSL, version catalog
• GitHub Actions CI/CD pipeline, 👷 efficient build pipeline, caching, integration tests, test report & failed test annotations
• 🚀 One-click release process + publish to Maven Central
• Security & 🚦 Vulnerability scan with trivy & GitHub CodeQL Analysis
• Automated dependency updates with Renovate 🤖
• Javadoc deployed with GitHub Pages
• Open Source Community ready (Code of Conduct, Contribution guidelines, Issue & PR Templates)

Quick Start

Demo on YouTube: java-library-template 1/7: Getting started (generate from; create PAT, one-click migrate)

1. Use this template to create your own repository

2. Create & provide a PAT (Personal Access Token) for the CI/CD pipeline

   Three workflows commit and push changes to the repository and therefore require additional permissions. ('migrate-repo-template', 'publish-javadoc', 'gradle-release')

   The jobs expect a secret by the name CI_GITHUB_TOKEN that holds a PAT with write permission for Content.

   To create a new access token, the following steps are required (ref GitHub documentation):

   1. If the new repo owner is an organisation, enrol the organisation for 'Fine-grained personal access tokens'. In the organisation 'Settings > Third-party Access > Personal access tokens'.

   2. Head to the Developer settings and enrol your personal account for the new 'Fine-grained personal access tokens'. (That's a one-off for your account and you might already have done this before)

   3. Next, click on the button 'Generate new token' and create a token for the target Resource owner, with access to your project and the following 'Repository Permissions'

      • Contents: Read and Write access to code
      • Metadata: Read access to metadata
      

   4. Provide your new PAT either as an Organisation secret or a Repository secret with the name CI_GITHUB_TOKEN.

      

3. Trigger the '!! INITIAL: Migrate Repo Template !!' workflow

   ℹ️ This workflow automatically 'migrates' all files in your new repository, updating the gradle project group, module name, package names, and all references to the repo <owner>/<name>.

   • Head over to Actions (1)
   • on the left-hand side select the topmost workflow '!! INITIAL: Migrate Repo Template !!' (2)
   • click the Run workflow button (3)
   • fill out the form & start the pipeline (4)(5)

   

4. Final one-off tasks

   • Choose & update the LICENSE, here
   • Update Maven Publication details here
   • Configure GitHub Pages to deploy branch 'gh-pages' (Javadoc)
   • Add secrets required for publishing to Maven Central
   • Install & configure renovate app (instructions)

Project Structure

The project template consists of three top-level folders:

• .github/: Defines the GitHub Actions CI tasks and templates for new pull requests, issues, etc.
• gradle/: Contains Gradle Configuration files such as the Gradle Version Catalog and the Gradle Wrapper.
• java-library-template/: The library source code (Gradle sub-project).

In addition, following files are worth highlighting:

• gradle/libs.versions.toml: A conventional file to declare a version catalog.
• settings.gradle.kts: The multi-project Gradle settings file. Here are all the sub-projects defined.
• gradle.properties: Holds the library version, needed & maintained by the CI/CD pipeline release process.
• **/build.gradle.kts: Gradle build file

CI/CD Pipeline

The heart of this template is the 'Main GitHub Actions CI/CD Pipeline'. See it in Actions (👻).

The workflow encompasses multiple jobs, modelled and linked with dependencies and conditions. Based on the context (trigger, ref, input arguments) it meets different use cases:

1. Check. Build, test, integration test; code quality & vulnerability scans.
   Runs for active PRs - as well as part of all subsequent listed use cases.
2. Latest. 'Check', publish SNAPSHOT version to Maven Central and Javadoc (GitHub Pages).
   Runs on pushes to the main branch.
3. Release Process. 'Check', executes (major|minor|patch) release process via the Gradle plugin.
   Manually triggered workflow via GitHub UI/API.
4. Library Release. 'Check', publish RELEASE version to Maven Central and Javadoc (GitHub Pages).
   Runs for pushed tags.

Publish to Maven Central

Automated Process

The Maven publish process is fully automated and does not require manual action.

• The main branch (per process definition) always is set to the next SNAPSHOT version and is published to the Sonatype snapshot repository with each main CI/CD pipeline run. The pipeline runs e.g. when a PR is merged, but can also be triggered manually.
• Release deployment happens when a new tag is pushed to GitHub. (Part of the release process)

Prerequisites: Sonatype Credentials & GPG Signing Key

The initial setup for your OSSRH repository requires some manual steps and human review (see why), after which your deployment process is typically modified to get components into OSSRH. These are all one time steps. I recommend to follow the official guide.

In order to deploy your components to OSSRH with Gradle, you have to meet the requirements for your metadata in the pom.xml as well as supply the required, signed components.

ℹ️ The publish process uses io.github.gradle-nexus.publish-plugin under the hood.

The gradle project as well as the CI/CD pipeline is already fully prepared for the publishing process. The GH actions job callable.publish-sonatype.yml requires the following Secrets:

Secret name	Value
OSSRH_USERNAME	The username of your OSSRH account. The first part of your OSSRH (Sonatype) user access token.
OSSRH_PASSWORD	The password of your OSSRH account. The second part of your OSSRH (Sonatype) user access token.
GPG_SIGNING_KEY	The GPG private key to sign your artifacts (in ascii-armored format). You can obtain it with gpg --armor --export-secret-keys <[email protected]> or you can create one key online on pgpkeygen.com.
GPG_SIGNING_PASSPHRASE	The passphrase for unlocking the secret key. (you picked it when creating the key).

Please define the secrets via your repository settings. (Settings > Security > Secrets and variables > Actions)

Release Process

Creating a Release

To release a new version via the CI/CD Pipeline, please follow the instructions below.

• Navigate to Actions (1)
• > Main Pipeline (2)
• Click 'Run workflow' button (3)
• Select a semver release type with the 'Release Library' dropdown (4)
• 'Run the workflow' (5)

The release process includes

• Pipeline run (incl. build & tests) that executes the release plugin (6)
• The release plugin first sets & commits the new version (7a)
• Creates & pushes a new tag (7b)
• Sets the main branch to the next SNAPSHOT version (7c)

The new version is automatically published to Maven Central! 🚀

Prerequisites: PAT provided as CI_GITHUB_TOKEN

The CI/CD 'gradle-release' job expects a secret by the name CI_GITHUB_TOKEN that holds a PAT (Personal Access Token) with permission to push tags as part of the release process.

If you have been following the Quick Start guide you should already have this configured. Please refer to 'Quick Start' step 2.

Javadoc

Use

A Javadoc website of your library, generated by gradle, is 'published' to GitHub Pages by the CI/CD pipeline. In addition to each released version, the current snapshot version (main branch) is published as current.
-> visit the live preview.

Prerequisites: Configure GitHub Pages

To host the generated Javadoc, configure GitHub Pages for your repository to deploy from branch gh-pages. You can also find all deployments under 'pages-build-deployment'.

ℹ️ The branch is created with the first CI/CD pipeline run. ('Publish javadoc' job)

Security & CodeQL Analysis

Common Vulnerabilities and Exposures (CVE)

The libraries gradle dependencies are scanned for known CVE with aquasecurity/trivy. The scan results can be reviewed and managed under 'Security > Vulnerability alerts > Code scanning'.

Scans are triggered

1. with each main CI/CD pipeline run
2. Scheduled (weekly) (ref)

Please refer to official GitHub documentation for more details.

Automated Dependency Updates with Renovate

ℹ️ Renovate (RenovateBot) is a software tool that automates the process of keeping software dependencies up-to-date by scanning code repositories, identifying outdated dependencies, and generating automated pull requests to update them.

It’s Open Source and Community-Driven, supports a wide range of programming languages and package managers, and integrates with GitHub & Gitlab as well as other popular CI/CD systems.

Dependency Dashboard

PRs created by renovate bot

Prerequisites: Enable & Configure Renovate

This template ships with a prepared renovate.json.

The recommended way to enable renovate is to use the Renovate GitHub App.

Credits

• inspired by https://github.com/cortinico/kotlin-android-template
• PR & issue templates copied / adapted from https://github.com/nuxt/nuxt

java-library-template by thriving.dev is licensed under CC BY-NC-SA 4.0