In this blog, we will see what a maven is and why we need maven
Let’s say we have got a requirement to build an application ., as per requirement we finished the coding part. For the application to run, we need application servers like tomcat , JBoss, Wildfly like this. We cannot deploy the code directly onto these application servers, we need to deploy a build artifact which is also called a package ., so to create the package we need a tool like Maven. Maven is a java build tool, for every language there are build tools available.
Java - ANT, Maven, Gradle
Python - PyBuild
.Net - NANT, MsBuild
We are specifically going for Maven as it has more features than the other two.
Maven is often chosen over other build tools like Ant and Gradle because it provides:
Dependency Management: Maven automatically downloads and manages dependencies from remote repositories, which is more seamless compared to Ant.
Convention over Configuration: Maven follows a standard directory structure and conventions, reducing the need for custom configurations compared to Ant.
Extensibility: Maven's plugin system is extensive, enabling support for various build tasks, integration tools, and automation.
Central Repository: Maven provides a centralized repository for dependency resolution, which is more integrated compared to Ant.
Declarative Build: Maven uses XML-based POM files for project configuration, making builds more standardized.
What is Maven?
Maven is a Java-based build tool, it is open source and used to create build artifacts.
Build artifact means jar/war/ear package, generally for Windows we use .exe or .msi file, same for java we will build jar/war/ear file .,
We can create package for various applications such as
Standalone Applications — contains java code - we will create a jar ( java archive )
Web Applications — contains java code + web content ( HTML , CSS, JS , Images , XML ) - we create war ( web archive )
Enterprise Applications — contains java code + web content + modules - we create ear (enterprise archive ) - for ear we need at least 1 war file.
Maven Directory Structure :
Once we install maven we can see these folders,
bin - contains binary files like mvn
conf - contains configuration files like settings.xml
lib - contains libraries
boot - contains files that are used at run time by maven software
For maven to install we need java so we need to install java first.
This is the pom.xml structure. pom stands for Project object model. In maven default script file name is pom.xml., using this script file we will generate the package.
pom.xml will be in XML format, XML is similar to HTML but here we can have custom tags and closing tags are compulsory.
Here, groupId is com.<companyname>, artifactId is the project name, version is the version number and packaging can be jar/war/ear.
Maven Repositories :
We have 3 kinds of repositories here,
Local Repository - The Maven local repository is a local folder that is used to store all the project dependencies. When we build a Maven project, all dependency files will be stored in our Maven local repository. By default, ~/.m2/repository is the default local repository we can also customize it by adding a tag <localRepository> in settings.xml
<localRepository> /home/ubuntu/mavenlocalrepository </localRepository>
Maven Central Repository - The central repository is provided by the maven community, it contains commonly used libraries, in case if libraries are not found in the local repository this central repository comes into the picture.
Maven Remote Repository - Generally organizations maintain their own repositories for the libraries which are being used for the project. This one differs from the local repository, this one can be said as nexus or JFrog and this is accessible only within the organization. For example, we have 5 jar files that are used by various teams so rather than keeping them in the maven central repository which is accessible by the public we can keep them in the nexus artifactory so only our company people can access these jar files.
Whenever we try to build maven first checks in the local repository and if dependencies are not present locally it checks in the central repository and downloads to local repository, and it will start the build process.
Lifecycles in Maven :
There are 3 life cycles in Maven.
- Clean
The goal of this lifecycle is to delete the previous builds.
command - mvn clean
- site
The goal is to generate documentation for our source code.
command - mvn site
- default
This default lifecycle contains many goals
validate: it will validate the directory structure and files
command - mvn validate
compile: it will compile the source code and unit test cases code
command - mvn compile
test: it will run the unit test cases
command - mvn test
package: it will create the package
command - mvn package
install: it will store the build artifact in the maven local repository
command - mvn install
deploy: it will store the build artifact in the maven remote repository
command - mvn deploy
In the case of the default lifecycle if we do mvn package it will execute validate, compile, test, and then package. So all the previous stages will be executed here.
If we give 2 goals it gets executed from left to right, mvn clean package - here it will execute the clean goal first and then the package goal.
To skip any stage we can use this,
mvn clean package -DskipTests - it will compile and skip unit test cases
mvn clean package -Dmaven.test.skip=true - it will skip compiling and running unit test cases
So once we do mvn package it will create a folder named as a target in the project repository., and the name of the package will be artifactId-Version.packaging. Based on these 3 the name will be assigned.
If we do mvn install it will download the package in ~/.m2/repository directory. Also, all the dependencies will also be present here.
If we do mvn package we know it will create a target directory and in that, there will be an artifact. Now if we do the mvn clean it will delete the target folder.
Using these goals we can generate build artifacts for standalone, web applications, and enterprise applications. We deploy this build artifact into the application server and we can run our applications.