- mvn clean removes old build files.
- mvn compile compiles the source code.
- mvn test runs tests.
- mvn package creates a jar or war file.
- mvn install installs the build into the local repository.
- mvn deploy uploads it to a remote repository.
- mvn clean install is commonly used for a fresh build.
- mvn test with parameters can run specific tests.
- mvn dependency tree shows dependencies.
The group ID and artifact ID are used together to uniquely identify a project in Maven.
The group ID represents the organization, company, or overall project category. It is usually written in a reverse domain name format. It helps group related projects together. For example, a company may use a single group ID for all its applications.
The artifact ID represents the specific project or module within that group. It is the name of the actual application or library being built.
In simple terms, the group ID tells who owns or maintains the project, and the artifact ID tells which exact project or module it is.
An archetype in Maven is a project template used to create a new Maven project with a predefined structure.
It helps you generate a standard project layout automatically, including folders, basic configuration, and a sample pom.xml file, instead of creating everything manually.
Archetypes ensure consistency across projects and save time when starting a new project.
In simple terms, an archetype is a blueprint for a Maven project.
In Maven, there are two settings files.
The first one is the user-level settings file. It is called settings.xml and it is located in the .m2 folder inside the user’s home directory. This file is specific to a user and is used to configure things like proxy, credentials, and local repositories.
The second one is the global-level settings file. It is also called settings.xml and it is located in the Maven installation directory under the conf folder. This file applies to all users on the system.
In a Maven project, the default directories defined in the POM are as follows.
The source directory is
src/main/java
This is where the main application source code is placed.
The test source directory is
src/test/java
This is where the test classes and test code are placed.
The build directory is
target
This directory is created during the build process and contains compiled classes, test results, and generated JAR or WAR files.
When you compile a Maven project, the class files are generated inside the target directory.
The compiled main application class files are stored in
target/classes
The compiled test class files are stored in
target/test-classes
In Maven, the Build (Default) lifecycle consists of several phases that are executed in a fixed order. In my project, these phases are used as follows.
The first phase is validate.
In this phase, Maven checks whether the project structure is correct and whether the pom.xml file has all required information. In our project, this ensures dependencies and configuration are valid before starting the build.
The next phase is compile.
Here, Maven compiles the main source code from src/main/java and generates class files in the target/classes directory. In our project, this is where the application code gets compiled.
The test phase comes next.
Maven runs the unit tests present in src/test/java using the Surefire plugin. In our project, this phase executes API automation tests written using Rest Assured.
After that is the package phase.
In this phase, Maven packages the compiled code into a JAR or WAR file. In our project, this creates the final build artifact that can be deployed or shared.
The verify phase runs next.
Maven performs additional checks to ensure the build is valid. In our project, this phase is sometimes used to run integration tests or validate reports.
The install phase follows.
Here, Maven installs the generated JAR or WAR file into the local Maven repository (.m2 folder). In our project, this allows other modules or projects to reuse the same artifact.
The final phase is deploy.
Maven uploads the artifact to a remote repository such as Nexus or Artifactory. In our project, this is used in CI/CD pipelines to make the build available for deployment.
