JabRef (Complex Gradle)

JabRefarrow-up-right is a complex Gradle multi-project with multiple application subprojects. This guide shows how to package it with jbundle.

Project Structure

JabRef uses a multi-module Gradle setup:

jabref/
├── settings.gradle.kts
├── build.gradle.kts
├── jabkit/
│   └── build.gradle.kts      # CLI tool (application plugin)
├── jabgui/
│   └── build.gradle.kts      # GUI application (application plugin)
├── jabsrv-cli/
│   └── build.gradle.kts      # Server CLI (application plugin)
├── jabls-cli/
│   └── build.gradle.kts      # Language server (application plugin)
└── jablib/
    └── build.gradle.kts      # Shared library (no application)

Auto-Detection

jbundle automatically detects multi-project builds by parsing settings.gradle.kts and scanning subprojects for the application plugin.

When multiple application subprojects are found, jbundle prompts for selection:

Building a Single Subproject

Using CLI Flag

Using Configuration File

Then simply:

Building All Subprojects

Use --all to build every application subproject at once:

Output:

Module Detection

JabRef uses Java modules with incubator features. jbundle extracts addModules from build.gradle.kts:

These modules are automatically included in the jlink runtime, combined with jdeps analysis.

Manual Module Override

If auto-detection misses modules or you want full control:

Or in configuration:

If JabRef's Gradle build already created a jlink image, reuse it:

This skips the JDK download and jlink steps, using the pre-built runtime.

Complete Configuration

Full jbundle.toml for JabRef:

CI/CD Integration

GitHub Actions

Troubleshooting

"No application subproject found"

Ensure subprojects have the application plugin:

"shadowJar task not found"

jbundle tries :subproject:shadowJar first, then falls back to :subproject:build. If you're not using Shadow plugin, ensure regular build produces a fat JAR.

Module resolution errors

If jdeps fails to detect all required modules, use --modules to specify them manually:

Build takes too long

For development iteration, consider:

  1. Using --jlink-runtime with a pre-built runtime

  2. Building only the subproject you're working on (not --all)

Last updated

Was this helpful?