Tool Arguments

Tool arguments

Compose arguments for other tools

Use -r, --resolve-options to name the standard options accepted by the consuming tool. Option specifications generally match the corresponding JDK option without the leading --:

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

Only requested options that apply to the resolved graph are emitted. The result is written to standard output by default; -w, --write-argfile <path> writes it as a Java argument file.

Graph-independent options do not require a root module. For example, jig -r release emits --release with the current JVM feature version. When a module graph is selected, source-module metadata determines the emitted release instead.

The --module option differs between JDK tools, so its output specification includes the required form:

• module=single emits one module name
• module=list emits a comma-separated list for tools such as javac and javadoc
• module=main emits a module and main class for tools such as java and jpackage
• module=roots emits one root with --module or multiple roots with --add-modules

module is an alias for module=single. module=roots must be accompanied by add-modules. With module=main and no -m, the only module declaring a main class is selected automatically. Select it explicitly when more than one module declares a main class.

Requesting module-source-path includes the static dependencies required by javac: direct static requirements of selected source modules and static transitive requirements inherited along their readability paths. Plain static requirements of compiled dependencies are not included. Requesting only module-path omits dependencies reachable only through requires static, even when jig compiles source modules internally.

Use --validate-runtime-access when the consuming operation will run code. Validation does not emit runtime access options; request those options explicitly with -r.

Invoke jig separately for each consuming tool. Use --help for the complete list of supported resolve options.

Resolve for a target platform

Published modules are placed on the generated module path as unclassified JARs by default.

--target-platform selects artifacts published with an os-maven-plugin classifier, falling back to an artifact without a classifier. Use --target-platform CURRENT to select the classifier for the current operating system and architecture. Classified JARs are considered only when this option is present.

--prefer-jmod selects a JMOD when one is available, falling back to a JAR. Without an explicit target platform, JMOD lookup tries the current operating system and architecture before an unclassified JMOD. This implicit JMOD target does not enable classified JAR selection.

A classified JAR or JMOD is an alternative artifact for the module already chosen by version resolution, not a separate resolution candidate. Before adding it to the generated module path, jig verifies that its module descriptor exactly matches the descriptor used during resolution. Repository checksums remain responsible for verifying the complete artifact contents.

For example, generate the module path and root modules accepted by jlink:

jig --prefer-jmod \
  --add-requires com.netflix.tools.ja@1.2.3 \
  -r module-path,add-modules

A dependency that replaces a system module must be placed on --upgrade-module-path. Because jlink does not accept that option, such a graph cannot be linked directly.