Getting Started

Complete an existing module path

For example, start with only the JUnit Jupiter root module:

jig --module-path /path/to/org.junit.jupiter-6.1.3.jar \
  --module org.junit.jupiter \
  --resolve-options module-path

The generated module path retains that JAR and adds its missing dependencies from Maven repositories:

--module-path
/path/to/org.junit.jupiter-6.1.3.jar:<repository>/org.junit.jupiter.api-6.1.3.jar:<repository>/org.junit.jupiter.engine-6.1.3.jar:<repository>/org.junit.jupiter.params-6.1.3.jar:<repository>/org.junit.platform.commons-6.1.3.jar:<repository>/org.junit.platform.engine-6.1.3.jar:<repository>/org.opentest4j-1.3.0.jar

The root module's descriptor supplies the dependency versions, so the local module path does not need to contain them in advance.

Compile a source module

Suppose src/com.example.app/module-info.java declares the application's entry point:

/**
 * @mainClass com.example.app.Main
 */
module com.example.app {
}

Generate the launch arguments and run the application:

output=/path/to/output
mkdir -p "$output"

jig --module-source-path src \
  -m com.example.app \
  -r module-path,module \
  -w "$output/launch.args"

java @"$output/launch.args"

Because the requested module-path requires the module in binary form and module-source-path was not requested, the source module is compiled into a global cache location. Later invocations without changes to the sources reuse this cached output.

The requested options determine how the source module is presented. Requesting only module-path produces one complete module-path entry:

jig --module-source-path src \
  -m com.example.app \
  -r module-path

--module-path
<complete-current-module>

Requesting patch-module allows unchanged content to remain in a reusable base:

--module-path
<reused-module-base>
--patch-module
com.example.app=<changed-module-content>
--module
com.example.app/com.example.app.Main

Both forms present the same module. The second avoids copying unchanged content into a new complete module. Classes, resources, and multi-release content are included in either form.

Compilation warnings from previous compilations are replayed prefixed with [diagnostics replayed from previous compilation] so they can be distinguished from feedback about the current change. Use --no-compile-diagnostics when the warnings are not useful to the caller, or --recompile to compile from source again.

Compile with an external compiler

Request both module-path and module-source-path to resolve dependencies, but keep selected source modules as source input for an external compiler:

output=/path/to/output
mkdir -p "$output/modules"

jig --module-source-path src \
  -m com.example.app \
  -r module-path,module-source-path,module=list,release \
  -w "$output/compile.args"

javac -d "$output/modules" @"$output/compile.args"

jig --module-path "$output/modules" \
  -m com.example.app \
  -r module-path,add-modules \
  -w "$output/launch.args"

java @"$output/launch.args" \
  --module com.example.app/com.example.app.Main

The first invocation generates the options needed by javac, including direct requires static dependencies of the source modules and requires static transitive dependencies inherited along their readability paths The second invocation uses the compiled output as its input and generates the runtime options needed by java.

Resolve published modules

Resolve modules directly by Java module name and version, without a source module or local JAR:

jig --add-requires org.junit.platform.console@6.1.2 \
  --add-requires org.junit.jupiter.engine@6.1.2 \
  -r module-path,add-modules

This flag may repeated or combined with source modules and an existing module path. Transitive dependencies are resolved using the versions recorded in module descriptors.

--add-modules can also name a module that is not yet on the module path, when another module in the graph declares a version for that module. A requires static directive can supply that version without selecting the static dependency itself. If no module supplies a version, use --add-requires <module>@<version> instead.

Look up a Maven artifact's module name

Find the Java module name provided by a Maven package:

jig --lookup-module pkg:maven/org.apache.commons/commons-configuration2@2.15.1

org.apache.commons.configuration2

Omit the version to inspect the latest available version:

jig --lookup-module pkg:maven/org.apache.commons/commons-configuration2

org.apache.commons.configuration2

A result is returned only when the artifact can subsequently be resolved by the returned module name. Repository access follows Maven settings.

Continue with tool arguments to compose options for javac, java, javadoc, jlink, and other tools.