--maven-aggregate-project
Options for Maven Projects.
Example for aggregate projects:snyk test --maven-aggregate-project
Ensure you run the options in the same directory as the root pom.xml file.
--maven-aggregate-project
Options for Maven Projects.
Example for aggregate projects:snyk monitor --maven-aggregate-project
Ensure you run the options in the same directory as the root pom.xml file.
--init-script=\ - Used for projects with a Gradle initialization script.
--init-script=\ - Used for projects with a Gradle initialization script.
Options for Gradle Projects.
snyk test -- \[\
Visit Options for build tools.
| | | Unmanaged JAR files |--scan-unmanaged - Tests unmanaged files
--scan-unmanaged --file=\ - Tests individual JAR, WAR, and AAR files
--scan-all-unmanaged - Auto-detects Maven, JAR, WAR, and AAR files recursively from the current folder.
Visit Options for unmanaged JAR files.
--scan-unmanaged - Tests unmanaged files
--scan-unmanaged --file=\ - Tests individual JAR, WAR, and AAR files
--scan-all-unmanaged - Auto-detects Maven, JAR, WAR, and AAR files recursively from the current folder.
Visit Options for 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: ``` snyk test --maven-aggregate-project ``` To scan non-aggregate Projects, use the `--all-projects` option: ``` snyk test --all-projects ``` You can use the same options with `snyk monitor`. The following example outlines how Maven-specific options are used with the Snyk CLI. 1. Test a specific Maven profile called “prod”. ``` snyk test -- -P prod ``` 2. Add a system property from your pom.xml file, for example, the package version that appears in your pom.xml: ``` ${pkg_version} ``` 3. Define the system property: ``` snyk test -- -Dpkg_version=1.4 ``` ## CLI help for Gradle Projects A Gradle build can consist of several sub-projects. Each sub-project has its own `build.gradle`, and only the root Project also includes a `settings.gradle` file. Sub-projects depend on the root Project but can be configured otherwise. By default, the 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: ``` snyk test --all-sub-projects ``` Each of the individual sub-projects appears as a separate Snyk Project in the Web UI. To scan a specific Project (for example, "myapp"), use the following command: ``` snyk test --sub-project=myapp ``` ### Gradle configurations Gradle dependencies are declared for a particular scope. Gradle represents each scope with [configurations](https://docs.gradle.org/current/userguide/declaring_dependencies.html#sec:what-are-dependency-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 includes 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. The CLI identifies all resolvable configurations that match the regex and aggregates their dependencies into a single scan result. If you require separate reports for different configurations (for example, compile versus runtime), run the command separately for each. * 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` to match `compile`, `testCompile`, `compileOnly`, and so on. * `--configuration-matching=^compile$` to match only `compile`. * `--configuration-matching='^(debug|release)compile$'` to match `debugCompile` and `releaseCompile`. * `--configuration-matching='^(?!test).*$'` to match all configurations except those starting with "test" (for example, excludes `testCompileClasspath`, `testRuntimeClasspath`). Snyk recommends this for Projects with large dependency graphs that hit maximum path limits, because excluding test configurations reduces the graph size while still covering production dependencies. ### Android build variants Android Gradle supports creating different versions of your app by configuring [build variants](https://developer.android.com/studio/build/build-variants). Because the Snyk default behavior is to merge all available configurations, the iterated variants cause a clash of configurations that cannot be merged. In these situations, the Snyk scan fails with an error from Gradle that can 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: 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: ``` --configuration-matching=prodReleaseRuntimeClasspath ``` * Explicitly specify the dependency configuration: modify intra-project dependencies in your `build.gradle` files to use a specific configuration. For example: ``` dependencies { implementation project(path: ':mymodulewithvariants', configuration: 'default') } ``` * Suggest configuration attributes: if you receive an error when running the command, the error can 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: ``` snyk test --configuration-attributes=buildtype:release,usage:java-runtime,mode:demo ``` matches the variants using `com.android.build.api.attributes.BuildTypeAttr=release` and `org.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'`. For tips on disabling the daemon, visit the [Gradle documentation](https://docs.gradle.org/current/userguide/gradle_daemon.html#sec:disabling_the_daemon). ### Lockfiles If your Gradle Project uses a single `gradle.lockfile` or multiple `*.lockfile` per configuration, the following error can appear: {% code overflow="wrap" %} ``` Gradle Error (short): > Could not resolve all dependencies for configuration ':compileOnly'. > Locking strict mode: Configuration ':compileOnly' is locked but does not have lock state. ``` {% endcode %} 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 recommends that you update the `build.gradle` file that contains your `dependencyLocking` logic with the following instruction: ``` compileOnly {resolutionStrategy.deactivateDependencyLocking() } ``` This ignores the `compileOnly` and saves only the necessary information to analyze your Project. If you have trouble testing your Gradle Projects with Snyk, contact Snyk support and provide the following details: * `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 [Apache Ant](https://ant.apache.org/) is a Java build system focused solely on executing build tasks defined in XML. [Apache Ivy](https://ant.apache.org/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`: ```xml