Java / Scala
FOSSA supports Java and Scala code via Maven, Gradle and Sbt.
Tool | Quick Import (app.fossa.com) | CLI (fossa-cli) |
---|---|---|
Maven | pom.xml | pom.xml |
Gradle | build.gradle or custom *.gradle | build.gradle |
Sbt (Scala Build Tool) | build.sbt | build.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
orbuild.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:
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):
id | url |
---|---|
central | https://repo1.maven.org/maven2 |
cloudera | https://repository.cloudera.com/artifactory/cloudera-repos |
conjars | http://conjars.org/repo |
cloudera-old | https://repository.cloudera.com/artifactory/repos |
hortonworks-releases | http://repo.hortonworks.com/content/repositories/releases/ |
mapr-releases | http://repository.mapr.com/maven/ |
jahia | http://maven.jahia.org/maven2/ |
atlassian-3rdparty | https://maven.atlassian.com/3rdparty/ |
pentaho | http://repository.pentaho.org/artifactory/repo/ |
http://maven.twttr.com/ | |
redhat-ga | https://maven.repository.redhat.com/ga/ |
datanucleus | http://www.datanucleus.org/downloads/maven2/ |
confluent | http://packages.confluent.io/maven/ |
sonatype-releases | https://oss.sonatype.org/content/repositories/releases/ |
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:
- Group ID
- Artifact ID
- 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:
- Maven (Supported)
- Ivy (Unsupported)
- 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.
Updated 4 months ago