maven.tar.gz

Maven is the de-facto build tool of choice for Java projects and has wide adoption at the enterprise level.

In this course, you will learn the fundamentals of Maven so that you can start to inject build automation into your own projects. You’ll start by exploring the basics such as plugins, goals, coordinates, and lifecycles.

In the latter half, you will dive into more advanced concepts such as dependencies, inheritance, aggregation, and build profiles. 

By the end of this course, you will have just the right amount of knowledge for you to quickly become productive when working with Maven.

Build Java Projects with Maven

In this lesson, we'll work with an example consisting of three related projects with the first one dependent on the second, and the second one dependent on the third.

When a dependency is specified it is also accompanied by a **_scope_**. The scope element controls two aspects: first, if a dependency should be included with the application packaging, and second, which _classpath_ a dependency should be included in. A **_classpath_** is the location of the classes and packages that a project is dependent on. For instance, in our three-project example. Project A depends on Project B. When compiling Project A, we need to inform the compiler of where to find the artifacts of Project B so that they can be used to compile Project A. If you were to use the Java compiler `javac` to compile Project A on the command line, you would specify the classpath as a command line argument using `-cp` or `-classpath`. The _scope_ element determines if a particular dependency is included in the classpath for a particular build task, e.g., when the project is being compiled or tested.

These scopes are discussed below:

1. **Compile**: This is the default scope for a dependency. The scope is set to compile if the `<scope>` element is not explicitly specified. Compile-scoped dependencies are available in all classpaths. For instance, the below example has a compile scope by default.

```xml
<dependency>
    <groupId>org.apache.hadoop</groupId>
    <artifactId>hadoop-common</artifactId>
    <version>3.3.0</version>
</dependency>
```

2. **Test**: Any dependencies that are only required for compiling and executing tests should be test-scoped. These dependencies aren't required for the execution of a project's artifacts and need not be included with the packaging. The standard use case for this scope is adding test libraries, e.g.,

```xml
<dependency>
    <groupId>junit</groupId>
    <artifactId>junit</artifactId>
    <version>3.8</version>
    <scope>test</scope>
</dependency>
```   

3. **Runtime**: Runtime-scoped dependencies are needed when the project executes or is being tested but are not required for compiling the project. Dependencies marked with the runtime scope will be present in runtime and test classpaths, but they will be missing from compile classpath. This is typically dynamically loaded code, such as JDBC drivers or MySQL connectors, which are not directly referenced in the program code. A runtime dependency is copied into your deployed application, but it is not available during compilation. This ensures that a developer doesn't mistakenly depend on a specific library that is intended to be a runtime dependency.

```xml
<dependency>
    <groupId>mysql</groupId>
    <artifactId>mysql-connector-java</artifactId>
    <version>8.0.21</version>
    <scope>runtime</scope>
</dependency>

```


4. **Provided**: Dependencies that are provided by the JDK or by a container, e.g., an application server or a servlet container, should be scoped as provided. As an example, consider you are developing a web application and would need the Servlet API available on the compile classpath to compile a servlet. However, you don't want to include the Servlet API in the packaged WAR file since the Servlet API jar will be supplied by your application server or the servlet container. Provided-scoped dependencies are available on the compile classpath, but not on the runtime classpath.

```xml
<dependency>
    <groupId>javax.servlet</groupId>
    <artifactId>servlet-api</artifactId>
    <version>3.0-alpha-1</version>
    <scope>provided</scope>
</dependency>
```


5. **System**: The system scope is similar to the provided scope, however, the difference is that in case of system-scoped dependencies the path to the dependency on the local machine is specified via the `<systemPath>` element. Maven will look for the dependency on the local machine at the specified path and not in the local or remote repository. This has the obvious disadvantage that other developers will be expected to have the dependency at the same path on their local machines in order to successfully build the project.

```xml
<dependency>
    <groupId>io.datajek</groupId>
    <artifactId>some-dependency</artifactId>
    <version>1.0</version>
    <scope>system</scope>
    <systemPath>${project.basedir}/libs/some-dependency-1.0.jar</systemPath>
</dependency>
```

6. **Import**: The import scope was introduced in Maven 2.0.9 and is only applicable to a dependency of type POM. An import-scoped dependency indicates that it should be replaced with the dependencies in its `<dependencyManagement>` section.

```xml
<dependency>
    <groupId>io.datajek</groupId>
    <artifactId>some-pom-dependency</artifactId>
    <version>2.0</version>
    <type>pom</type>
    <scope>import</scope>
</dependency>
```


We'll work with an example setup with the following dependency graph:

This lesson explains the dependency scope attribute of the dependency element and how it affects the various classpaths.

Theory

Dependency Scopes