Saved searches

Use saved searches to filter your results more quickly

Cancel Create saved search Sign up Reseting focus

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session.

mvn-clean-install-a-short-guide-to-maven.adoc

Latest commit

History

298 lines (207 loc) · 14.6 KB

mvn-clean-install-a-short-guide-to-maven.adoc

File metadata and controls

298 lines (207 loc) · 14.6 KB

mvn clean install - a short guide to Maven

What does mvn clean install do?

The short answer

Apache Maven is a popular build tool, that takes your project’s Java source code, compiles it, tests it and converts it into an executable Java program: either a .jar or a .war file.

mvn clean install is the command to do just that.

  1. You are calling the mvn executable, which means you need Maven installed on your machine. (see How do you install Maven?)
  2. You are using the clean command, which will delete all previously compiled Java .class files and resources (like .properties) in your project. Your build will start from a clean slate.
  3. Install will then compile, test & package your Java project and even install/copy your built .jar/.war file into your local Maven repository. (see A look at the Maven build lifecycle: phases)

The (short) long answer:

There is more to Maven than a couple lines on 'mvn clean install'. If you want to learn about how Maven’s dependency management and build cycle works, or how to avoid the most common pitfalls when working with it: Read on.

Maven: Crash-Course

Maven is one of the most popular build tools in the Java universe (others being Gradle or old-school Ant). You can not only build Java projects with it, but pretty much every project written in a JVM language like Kotlin or Scala, as well as other languages like C# and Ruby.

Now what exactly does a build tool do? Maven does three things rather well:

  1. Dependency Management: Maven lets you easily include 3rd party dependencies (think libraries/frameworks such as Spring) in your project. An equivalent in other languages would be Javascript’s npm, Ruby’s gems or PHP’s composer.
  2. Compilation through convention: In theory you could compile big Java projects with a ton of classes, by hand with the javac command line compiler (or automate that with a bash script). This does however only work for toy projects. Maven expects a certain directory structure for your Java source code to live in and when you later do a mvn clean install , the whole compilation and packaging work will be done for you.
  3. Everything Java: Maven can also run code quality checks, execute test cases and even deploy applications to remote servers, through plugins. Pretty much every possible task you can think of.

Maven’s directory layout

Maven’s pom.xml

Technically, any directory that contains a pom.xml file is also a valid Maven project. A pom.xml file contains everything needed to describe your Java project. Let’s have a look at a minimal version:

xml version="1.0" encoding="UTF-8"?> project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> modelVersion>4.0.0modelVersion> groupId>com.marcobehlergroupId> artifactId>my-projectartifactId> (1) version>1.0-SNAPSHOTversion> (2) properties> maven.compiler.source>1.8maven.compiler.source> (3) maven.compiler.target>1.8maven.compiler.target> project.build.sourceEncoding>UTF-8project.build.sourceEncoding> properties> dependencies> dependency> (4) groupId>junitgroupId> artifactId>junitartifactId> version>4.12version> scope>testscope> dependency> dependencies> project>
  1. We are defining a project called 'my-project'
  2. With a version number of 1.0-SNAPSHOT, i.e. work-in-progress
  3. Using Java 1.8 for compilation
  4. With one dependency needed for unit testing: junit in version 4.12

Maven’s src & target folders

Apart from a pom.xml file, you also need Java source code for Maven to do its magic, whenever you are calling mvn clean install . By convention:

In the end, your project will look like this:

+ myproject + -- src + -- main + -- java MyApp.java + -- target + -- classes (after 'mvn compile') MyApp.class myproject.jar (upon mvn package or mvn install) pom.xml

Now that you have a pom.xml file, as well as a src folder, you still need Maven installed on your machine. Let’s do that now.

How do you install Maven?

Installing Maven is rather simple. Similar to Java it is just a .zip file that you need to download and put anywhere on your harddrive. The .zip file’s contents look like this:

Directory c:\dev\apache-maven-3.6.3 12.07.2019 09:25 . 12.07.2019 09:25 .. 12.07.2019 09:25 bin 12.07.2019 09:25 boot 12.07.2019 09:25 conf 12.07.2019 09:25 lib 12.07.2019 09:24 13.437 LICENSE 12.07.2019 09:24 182 NOTICE 12.07.2019 09:24 2.533 README.txt

Now you need to make sure to add the /bin directory to your PATH variable, otherwise you cannot call 'mvn' (think: mvn clean install) from anywhere. That’s it.

If you are unsure about any of these two steps, there’s a great video on Youtube, showing how to install the latest Maven 3.6 on Windows.

A look at the Maven build lifecycle: phases

Now what really happens when you execute a mvn clean install in your project? Maven has the concept of a build lifecycle, which is made up of different phases.

Here’s what Maven’s default lifecycle looks like (note: it is missing 'clean').

+-------------------------------+ +-------------------------------+ +-------------------------------+ | | | | | | | | | | | | | *validate* |+--->| *compile* |+--->| *test* |+--> | | | | | | | (are my pom.xmls correct?) | | (MyApp.java -> MyApp.class) | | (run unit tests) | | | | | | | +-------------------------------+ +-------------------------------+ +-------------------------------+ +-------------------------------+ +-------------------------------+ +-------------------------------+ | | | | | | | | | | | | | *package* |+--->| *verify* |+--->| *install* |+--> | | | | | | | (MyApp.class -> MyApp.jar) | | (run integration tests) | | (cp myapp.jar to | | | | | | ~/.m2/repository/com/ | | | | | | marcobehler/myapp/myapp.jar | +-------------------------------+ +-------------------------------+ +-------------------------------+ +-------------------------------+ | | | | | *deploy* | | | | cp myApp.jar to a | | remote Maven repository | | | +-------------------------------+

These phases are sequential and depend on each other.

Example:

When you call mvn deploy , mvn will also execute every lifecycle phase before deploy , in order: validate , compile , test , package , verify , install .

Same for verify : validate , compile , test , package . Same for all other phases.

And as clean is not part of Maven’s default lifecycle, you end up with commands like mvn clean install or mvn clean package . Install or package will trigger all preceding phases, but you need to specify clean in addition.

Where does Maven store 3rd party libraries?

Contrary to other languages, where project dependencies are stored in your project’s directory, Maven has the concept of repositories.

There are local repositories (in your user’s home directory: ~/.m2/) and remote repositories. Remote repositories could be internal, company-wide repositories like Artifactory or Nexus or the (reference) global repo at https://repo.maven.apache.org/maven2/.

Maven will always download your project dependencies into your local maven repository first and then reference them for your build. When you think back at your pom.xml file from before:

dependencies> dependency> groupId>junitgroupId> artifactId>junitartifactId> version>4.12version> scope>testscope> dependency> dependencies>

Then mvn will, once you try and "mvn test" your project, download the junit dependency into ~/.m2/repository/junit/junit/4.12/junit-4.12.jar and reference it via Java’s classpath mechanism for your build.