Skip to content

Dependencies

Estimated time to read: 3 minutes

Dependencies are other resources that are used within the application.

Dependencies are added to the pom.xml file. Maven will automatically acquire any transitive dependencies as needed.

 <dependencies>
  <dependency>
   <groupId>org.apache.commons</groupId>
   <artifactId>commons-lang3</artifactId>
   <version>3.3.1</version>
  </dependency>
 </dependencies>

Versions

Versions are the release number of the artefact that is acquired for the build.

Version naming

SNAPSHOT

All internal development should built as a SNAPSHOT. SNAPSHOT releases are typically used for test development or for nightly code builds from tools such as Jenkins, Travis, etc.

Release

Release naming generally does not have follow any conventions. However, there are various conventions that can be used such as:

  • myapp-1.0-M1.jar (Milestone)
  • myapp-1.0-RC1.jar (Release Candidate)
  • myapp-1.0-RELEASE.jar (Release)

Other conventions

Other than the SNAPSHOT convention, there are no other conventions when it comes to naming Java packages.

Types

Packaging Types refer to packaging inside of the application. When building a package that other people will consume, that is referenced with the packaging type inside of the pom.xml.

Types refer to the type of resource that is included in the application. The current core packaging types are:

  • pom
  • jar
  • maven-plugin
  • war
  • ear
  • par

Type: *ar

For the most part, any ear, jar, par or war files are basically just Zip files with a specific extension.

Jar files are typically the default output from Maven.

Type: Pom

All of the dependencies inside of the pom are downloaded into the application.

Transitive Dependencies

Maven will automatically download any transitive dependencies for dependencies that have been added to the application. By default, Maven will attempt to download the most recent version of a transitive dependency unless it has been excluded.

Transitive dependencies, and their versions, are often set by the developer of the dependency that is being imported into the project. You are somewhat reliant on this being maintained. For example, if there is a security issue with a transitive dependency, it may not automatically be obtained!

Example pom.xml with Dependencies

<project>

 <groupId>io.entityfour</groupId>
 <artifactId>HelloWorld</artifactId>
 <version>1.0-SNAPSHOT</version>
 <modelVersion>4.0.0</modelVersion>
 <packaging>jar</packaging>
 <build>
  <plugins>
     <plugin>
       <groupId>org.apache.maven.plugins</groupId>
       <artifactId>maven-compiler-plugin<artifactId>
       <version>3.8.0</version>
       <configuration>
         <release>12</release>
       </configuration>
     </plugin>
  </plugins>

 <dependencies>
  <dependency>
   <groupId>org.apache.commons</groupId>
   <artifactId>commons-lang3</artifactId>
   <version>3.3.1</version>
  </dependency>
 </dependencies>

</project>

Dependencies are imported by their naming convention. This is made up of their groupId, artifactId and version.

Scopes

Maven has six scopes available its build system

  • compile - This is implicit. - All resources are available everywhere within the application.
  • provided - The artefact is available throughout the entire build system.
  • runtime - Not needed for compilation but is required for execution. Effectively acts as the opposite to provided.
  • test - Test is only available for the test, compilation and execution phase. It does nothing for the packaging.
  • system - Do not use. This hardcodes a path to a jar in the filesystem!
  • import - Deals with dependency management and shares multiple artefacts across multiple pom files