Java / Scala

FOSSA supports Java and Scala code via Maven, Gradle and Sbt.

Quick Import (app.fossa.com)

After importing Java code, FOSSA will attempt to get results out of the box by incrementally running your build and statically resolving dependency signatures that are produced.

This method supports a wide variety of build states, but will often require configuration or inlined settings for more complicated builds.

📘

Repository Scanning in the Java Ecosystem

Since Java builds are generally complicated, it is both impossible to generically build codebases OR get accurate results from pure static analysis of pom.xml or build.gradle files.

For larger builds that require significant configuration, we recommend using CI/CD Scanning for fast and accurate results. Scroll down to view the CI/CD Scanning documentation.

Configuring Repository Scanning

FOSSA provides a wide variety of options to configure Java ecosystem builds under each project's settings page (Project > Settings > Builds & Languages > Java):

To provide the best OOTB experience, FOSSA will elect sane defaults and configuration magic. These include choosing only compile and runtime scopes, setting default build profiles, intelligently handling optional dependencies and more.

📘

Default Handling for Java Build Parameters

FOSSA automatically provides handling logic for optional dependencies, scopes, transitive dependencies, tags and more. See the Extended Documentation section at the bottom of this page.

If you'd like to provide any environment variables (such as GRADLE_OPTS) during Repository Scanning, you can add them under Project Settings > Builds and Languages > General.

Learn more about customizing [Repository Scanning](doc: automated-builds).

CLI (fossa-cli)

For complex builds, you can use fossa-cli, our open-sourced dependency analysis client, to upload results from an existing Java build in CI or on your local development machine.

To get started, install the latest release of fossa-cli from our GitHub releases page:

curl -H 'Cache-Control: no-cache' https://raw.githubusercontent.com/fossas/fossa-cli/master/install-latest.sh | bash

Once installed, run fossa analyze inside of your repo's root directory. Below, we've included extended documentation on configuring for different ecosystems:

• Maven
• Gradle
• Sbt

Since fossa-cli is open source, you can view our raw implementation of how we get dependency data directly in the repo.

Authentication

FOSSA can fetch and resolve dependencies from private registries like Artifactory, Nexus, or any custom public Maven registry.

To customize how FOSSA handles Java dependencies, visit your Java Language Settings under Account Settings > Languages > Java.

By default, when FOSSA encounters a package in the Java ecosystem, it will try to resolve it from the following public registries (in order):

Adding a Public Registry

To add a new public registry, you can simply add a new entry under Repositories and FOSSA will begin checking that registry (in order) for packages that your projects are bringing in.

Adding a Private Registry

To add an authenticated registry, add two entries to Repositories and Servers with a corresponding Id and include your credentials under the Servers entry:

Improving Resolution Performance

If you know what registries you'd like FOSSA to prefer, you can re-order to your preference in the Java Language Settings. This way, if you have a set of registries that you know will succeed, FOSSA will check those first and resolve dependencies without having to cycle through subsequent registries.

Package Data

FOSSA will parse data from all package metadata as well as scan all code provided in an artifact or associated code archives. If references to license webpages are found, FOSSA will crawl the web to seek licensing information.

In cases where no source code is included in an artifact, FOSSA will attempt to resolve it to a known codebase that the artifact was built from and perform a full code audit.

In the Java ecosystem, it is common for license data to be stripped when artifacts are published. In these cases, license data can be regenerated from the FOSSA registry by enriching build artifacts with data from associated VCSs, parent artifacts and more.

If FOSSA encounters a META-INF folder in a Maven archive, it treats it as data from deeper dependencies.

Extended Documentation on Repository Scanning

In this section, you'll find extended documentation on how FOSSA's Repository Scanning resolves dependencies. If you are using CI/CD Scanning, then these notes do not apply.

Maven Dependencies

The Maven build system (http://maven.apache.org/) pulls in dependencies based on:

1. Group ID
2. Artifact ID
3. Version

FOSSA derives dependencies by building your project and seeing which dependencies are brought in. Other metadata is fetched directly from repositories.

Here's some of the metadata that's pulled in:

• Home page URL
• Dependencies
  • Group ID
  • Artifact ID
  • Resolved version
  • Transitive excludes
  • Optional
  • Scopes

Optional

Optional dependencies are included in analysis and are grokked by FOSSA. The optional dependencies are tagged as Optional by FOSSA and are not included beyond depth 1.

Scope

Dependency Scope is included in analysis and is selectable in FOSSA. Choosing different project scopes allows you to choose which dependencies are included in issue scans and in the UI.

Transitive Excludes

Dependencies that are excluded transitively are also grokked by FOSSA. If a transitive dependency is explicitly excluded, FOSSA will exclude that dependency from its issue scans and in the UI. If another dependency brings in the excluded transitive dependency, then it will be included. These excludes are scoped to dependencies, not projects.

Scala Dependencies

The Scala build tool (http://www.scala-sbt.org/) pulls in dependencies from several kinds of repositories. FOSSA can scan them if they are published in the Maven-compatible file layout (default). FOSSA does not yet support artifacts in the Ivy file layout.

Gradle Dependencies

The Gradle build system (https://docs.gradle.org/) pulls in dependencies based on the repository it's pulling from:

1. Maven (Supported)
2. Ivy (Unsupported)
3. Local (Unsupported)

The metadata pulled in is similar to maven:

• Available versions
• Home page URL
• Dependencies
  • Group ID
  • Artifact ID
  • Resolved version
  • Transitive excludes
  • Scopes

Properties

Gradle properties can be set via environment variables as defined above. Gradle property names should be prefixed with ORG_GRADLE_PROJECT_ as per the gradle documentation.