Snyk CLI for Java and Kotlin
Use the snyk test
command to test Maven and Gradle Projects as follows:
Snyk CLI with Gradle: To build the dependency graph, Snyk integrates with Gradle and inspects the dependencies reported by the tool. The following manifest files are supported:
build.gradle
(Groovy DSL) andbuild.gradle.kts
(Kotlin DSL).Snyk CLI with Maven: To build the dependency tree, Snyk integrates with Maven and inspects the dependencies reported by the tool. The following manifest files are supported:
pom.xml
.
This page provides details about how to use the Snyk CLI help for Maven and Gradle Projects and also provides a workaround for ant
and ivy
.
The following table lists options to start scanning your dependencies. It covers the snyk test
and snyk monitor
commands. For a list of all the options for these commands, see the CLI commands and options summary.
Package manager | Test help | Monitor help |
---|---|---|
Maven | ||
Gradle |
|
|
Build tools | ||
Unmanaged JAR files |
|
|
CLI help for Maven Projects
A Maven aggregate Project is one that uses modules and inheritance.
When scanning these types of Projects, Snyk performs a compile to ensure all modules are fixable by the Maven reactor.
To scan aggregate Projects, use the
--maven-aggregate-project
option:To scan non-aggregate Projects, use the
--all-projects
option:
The same options can be used with snyk monitor
.
Be sure to execute the options in the same directory as the root pom.xml file.
Each of the individual sub-projects appears as a separate Snyk Project in the Web UI.
Refer to the following example to see how Maven-specific options are used with the Snyk CLI.
Test a specific Maven profile called “prod”.
Add a system property from your pom.xml file, for example, the package version that appears in your pom.xml:
Define the system property like this:
CLI help for Gradle Projects
Gradle build can consist of several sub-projects, where each sub-project has its own build.gradle, while the root Project is the only one that also includes a settings.gradle
file. Sub-projects depend on the root ProjectProjects but can be configured otherwise.
By default, Snyk CLI scans only the current Project, the Project in the root of the current folder, or the Project that is specified by --file=path/to/build.gradle
).
To scan all Projects at once (recommended), use the
--all-sub-projects
option:
Each of the individual sub-projects appears as a separate Snyk Project in the Web UI.
To scan a specific Project (for example, myapp):
Gradle configurations
Gradle dependencies are declared for a particular scope; each scope is represented by Gradle with the help of Configurations. For example:
implementation: configuration for dependencies required at compile time and runtime, but not exposed to consumers.
api: configuration for dependencies required at compile time and runtime, and exposed to consumers.
compileOnly: configuration for dependencies required only at compile time.
runtimeOnly: configuration for dependencies required only at runtime.
compileClasspath: configuration for dependencies required at compile time.
In most cases, Snyk will include all the dependencies in the compileClasspath configuration, but this can vary in some circumstances.
To test a specific configuration:
Use the
--configuration-matching
option with a Java regular expression (case-insensitive) as its parameter. Note that only the first configuration that matches is tested.If the different sub-projects include different configurations, scan each sub-project separately.
Examples of how you can use the --configuration-matching option
--configuration-matching=compile
will match compile, testCompile, compileOnly, and so on.--configuration-matching=^compile$
will match only compile.--configuration-matching='^(debug|release)compile$'
will match debugCompile and releaseCompile.--configuration-matching='^(?!.*test).*$'
will match all configurations except those containing the string "test".
Android build variants
Android Gradle supports creating different versions of your app by configuring build variants.
Because the Snyk default behavior is to merge all available configurations, the iterated variants cause a clash of configurations that can't be merged.
In these situations, the Snyk scan fails with an error from Gradle which may contain one of the following messages:
Cannot choose between the following configurations of
project :mymodulewithvariants
Cannot choose between the following variants of
project :mymodulewithvariants
Could not select value from candidates
To avoid such conflicts:
Use a specific configuration(s): if you know of a build configuration that has all the required attributes and the configuration is identical across all sub-projects included in the test, specify that configuration. For example:
Explicitly specify the dependency configuration: modify intra-project dependencies in your build.gradle file(s) to use a specific configuration
Suggest configuration attributes: if you receive an error when running the command, the error may indicate which attribute values are available, while the error details from Gradle also indicate which dependency variants match which attributes. Using these details, add the attribute filter option. For example:
matches the variants using
com.android.build.api.attributes.BuildTypeAttr=release
andorg.gradle.usage=java-runtime
Daemon
By default, Snyk passes gradle build --no-daemon
in the background when running snyk test
and snyk monitor
on Windows.
If you see snyk test
or snyk monitor
fail on other operating systems because of daemon-related issues, try adding the --no-daemon
flag to the Snyk command or set GRADLE_OPTS: '-Dorg.gradle.daemon=false'
.
See the Gradle documentation for tips on disabling the daemon.
Lockfiles
If your Gradle Project makes use of a single gradle.lockfile
or multiple *.lockfile
per configuration, you may see the following issue:
The compileOnly configuration has been deprecated, and even if your Project successfully generates a lockfile, the compileOnly
state is not included because this configuration cannot be resolved.
Only resolvable configurations compute a dependency graph. To solve this issue, Snyk suggests you update your build.gradle
containing dependencyLocking
logic with the following instruction:
This ignores the compileOnly and saves only the necessary information to analyze your Project.
Getting help
If you are having any trouble testing your Gradle Projects with Snyk, collect the following details and send them to Snyk at support@snyk.io:
build.gradle
settings.gradle
(especially if Snyk did not pick up a version of a package)The output from the following commands:
$ snyk test -d
$ gradle dependencies -q
Workaround for ant
and ivy
ant
and ivy
Apache Ant is a Java build system focused solely on executing build tasks defined in XML. Apache Ivy extends Ant by adding dependency management, handling library retrieval and transitive dependencies, which Ant alone does not manage.
Ivy dependencies are configured in an XML file, for example ivy.xml
:
Such a dependency file is typically evaluated using an ant
task defined in build.xml
:
Using the command ant resolve-dependencies
, dependencies will be downloaded from Maven Central, just like regular Maven dependencies.
To let Snyk know about the dependency tree, you must first convert to the Maven POM format. Start by configuring a new makepom
task in build.xml
With this, you can now run the following commands:
The pom.xml
file does not need to be checked in and can be deleted after a test is done using snyk
. Additionally, the dependency tree can be monitored using: