In this tutorial, we will Discuss the Integration of Maven with Eclipse and TestNG, Maven Dependency Scope, and Maven Deployment Automation in detail:
In the previous tutorial, we discussed the comparison between Gradle vs Maven and Maven Plugins. This tutorial explains how to integrate Maven with other tools, Maven dependency, and Maven Deployment.
Let’s get started!
=> Visit Here For The Exclusive Maven Training Tutorial Series.
Table of Contents:
Integration Of Maven With Eclipse
How to integrate Maven with Eclipse has already been discussed in-depth on this page
In certain scenarios where we build a Maven project from the command prompt and we need to bring that project to Eclipse, then the following steps are to be executed.
#1) Navigate to the location of the pom file for the Maven project. Run the below command.
mvn eclipse:eclipse
#2) .classpath and .project will be created in the location of the Maven project.
Verify if the Maven plugin is already provided in the Eclipse from Windows =>Preferences, Maven should be present there. All the current Eclipse versions have the Maven plugins by default and if it is not there, we can get it from here.
#3) Now to make Maven and Eclipse work in conjunction, import the Maven project from the File. Then select the Existing Maven Project.
#4) Browse the location of the project and Proceed.
The image depicted above shows the Maven Project imported to Eclipse.
Integration Of Maven With TestNG
How to integrate Maven with TestNG has been discussed in-depth on the below page.
=> Integration Of Maven With TestNg Using Maven Surefire Plugin
While we have integrated Maven with TestNG in our project, there may be situations where our project has more than one Testng xml files. For example, the whole regression suite features are described in one testng.xml and sanity test cases are described in the other testng.xml file.
In a situation like this, we need to use the profile concept in Maven. In the pom file, we have to define the profiles. Each <profile> is a part of <profiles> tag and has a <id> associated with it.
A pom.xml file having profiles code snippet is given below:
<profiles>
<profile>
<id> Regression </id>
<build>
<pluginManagement>
<plugins>
<plugin>
<groupId> org.apache.maven.plugins </groupId>
<artifactId> maven-surefire-plugin </artifactId>
<version> 2.20.1 </version>
<configuration>
<suiteXmlFiles>
<suiteXmlFile> testngRegression.xml </suiteXmlFile>
</suiteXmlFiles>
</configuration>
</plugin>
</plugins>
</pluginManagement>
</build>
</profile>
<profile>
<id> Sanity </id>
<build>
<pluginManagement>
<plugins>
<plugin>
<groupId> org.apache.maven.plugins </groupId>
<artifactId> maven-surefire-plugin </artifactId>
<version>2.20.1</version>
<configuration>
<suiteXmlFiles>
<suiteXmlFile> testngSanity.xml </suiteXmlFile>
</suiteXmlFiles>
</configuration>
</plugin>
</plugins>
</pluginManagement>
</build>
Please note that we have two profiles above, described under <profiles> and each profile has an id associated with it. For example, Regression and Sanity also, under the suiteXmlFiles, we defined the name of the Testng xml file corresponding to the id (testngRegression.xml and testngSanity.xml).
Thus we have two profiles here and we can control each Testng file with the help of a single pom file.
Now in order to trigger a test case for each Testng file directly from the command prompt, we need to move to the project folder and run the following command.
mvn test –PRegression
Once this is executed, Maven searches the profile with the id Regression and the corresponding testngRegression.xml file. Thus only the tests involved there get executed.
Similarly, for a profile with id Sanity, the command is:
mvn test –PSanity
Here the testngSanity.xml file is used for determining the test cases to be executed. Thus for triggering a particular set of test cases, we need not modify the TestNG file name in the pom, rather it can be easily be achieved by maintaining separate TestNG files.
In the pom file, we can map these files and finally run them with the help of profiles in Maven from the command prompt.
Maven Dependency Scope
Maven has a total of six scopes as listed below.
- Provided
- Test
- System
- Import
- Compile
- Runtime
#1) Runtime Scope
Maven dependency has a scope as the runtime and is not used for build purposes. It constitutes of classpath for running and testing of the project. The below code snippet shows a runtime scope dependency.
<dependency>
<groupId> com.softwaretesting </groupId>
<artifactId> MavenJava </artifactId>
<version> 2.3 </version>
<scope> runtime </scope>
</dependency>
#2) System Scope
Maven dependency with scope as a system has a resemblance to the provided scope. System dependencies cannot be downloaded from the remote repository and are generally located in the project’s directories. The below code snippet shows a system scope dependency.
<dependency>
<groupId> com.software </groupId>
<artifactId> MavenJava1 </artifactId>
<scope> system </scope>
<version> 3.0 </version>
<systemPath> ${dir}\war\WEB-INF\lib\dep.jar </systemPath>
</dependency>
#3) Provided Scope
Maven dependency that has a scope as provided is required for building and testing of the projects. It is not recommended to export this dependency, as they are available at the runtime. However, this dependency is required for running the build. The below code snippet shows a provided scope dependency.
<dependency>
<groupId> com.test </groupId>
<artifactId> MavenJava2 </artifactId>
<version> 5.1.1 </version>
<scope> provided </scope>
</dependency>
#4) Test Scope
Maven dependency that has a scope of the test is not required for the building and running of the project. They are essentially used for compiling and running the unit test cases. The below code snippet shows a test scope dependency.
<dependency>
<groupId> com.testing </groupId>
<artifactId> MavenJava3 </artifactId>
<version> 1.0.2 </version>
<scope> test </scope>
</dependency>
#5) Import Scope
Inside the pom file, the dependencyManagement section contains the scope import. This signifies the dependency to be changed with the effective group of dependencies provided in the dependencyManagement section of the pom file. The below code snippet shows an import scope dependency.
<dependencyManagement>
<dependencies>
<dependency>
<groupId> com.testhelp </groupId>
<artifactId> MavenJava4 </artifactId>
<version> SNAP </version>
<scope> import </scope>
<type> pom </type>
</dependency>
</dependencies>
</dependencyManagement>
#6) Compile Scope
Maven dependency that has a scope of compile is the default one. This dependency is essential for building, testing, and running of the project. This is mostly important to solve Java source code having import statements. The below code snippet shows a compile scope dependency.
<dependencies>
<dependency>
<groupId> logging </groupId>
<artifactId> log </artifactId>
<version> 2.1.3 </version>
<scope> compile </scope>
</dependency>
</dependencies>
Maven Deployment Automation
Project deployment is a critical phase and involves multiple steps defined as listed below:
- The code developed to be checked in the repository.
- Source code to be downloaded from the repository.
- Compilation and building the application and generating JAR or WAR files.
- Putting the identified JAR or WAR files in a familiar network location.
- Load the JAR or WAR files.
- Deploy the downloaded JAR or WAR files to the target server.
- The new version number of application and the date to be updated in the documentation.
The above-mentioned steps are followed by each member of the teams involved in the project. Out of the above-listed steps, if anyone is missed or anything is not properly done, then, it results in failure of build and deployment. So in between, if there are any errors, they need to be fixed automatically.
Maven follows the deployment automation method in order to make deployment automatic and robust. This is achieved by the combination of the processes listed below:
- Building and release of the project to be taken care of by Maven.
- Source code to be managed by subversion and source code repository.
- Project binaries to take care of the remote repository manager.
Maven’s automated build and release process are taken care of by Maven Release plug- in. The pom.xml file should be updated as depicted below.
The below code is for the com.softwaretestHelp project pom.xml
< 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/maven-v4_0_0.xsd">
<modelVersion> 4.0.0 </modelVersion>
<groupId> com.softwaretestHelp </groupId>
<artifactId> TestApplication </artifactId>
<packaging> war </packaging>
<version> 2.0 </version>
<name> WebTest Maven Java </name>
<url> http://maven.apache.org </url>
<scm>
<url>http://www.svn.com</url> <connection>scm:svn:http://localhost:8080/svn/jrepo/trunk/Framework</connection>
<developerConnection>
scm:svn:testing/test@localhost:8080:common_core_api:1101:code
</developerConnection>
</scm>
<distributionManagement>
<repository>
<id> SampleTest-Web-Release </id>
<name> Release repository </name>
<url>
http://localhost:8082/nexus/content/repositories/SampleTest-Web-Release
</url>
</repository>
</distributionManagement>
<build>
<plugins>
<plugin>
<groupId> org.apache.maven.plugins </groupId>
<artifactId> maven-release-plugin </artifactId>
<version> 2.0-beta-9 </version>
<configuration>
<useReleaseProfile> false </useReleaseProfile>
<goals> deploy </goals>
<scmCommentPrefix> [SampleTest-Web- checkin] </scmCommentPrefix>
</configuration>
</plugin>
</plugins>
</build>
<dependencies>
<dependency>
<groupId> junit </groupId>
<artifactId> junit </artifactId>
<version> 3.9 </version>
<scope> test </scope>
</dependency>
</dependencies>
</project>
The salient features in the above pom.xml file are listed below:
- SCM: The location of SVN (where the source code is present) is configured by SCM.
- Repositories: This is the location of the JAR or WAR or EAR files or any other project artifact after the successful completion of the building the project.
- Plug-in: Deployment automation carried out by the Maven release plugin.
Maven Release Plugin
Maven release plugin carries out the following activities:
- mvn release:clean – It cleans the workspace of the previous build before the arrival of the future build.
- mvn release: rollback – In case of failure of the previous build, it rollbacks to the workspace.
- mvn release:prepare – It verifies if there are any uncommitted changes in files or not. Also, checks the snapshot dependencies and updates the version number of the application. It modifies the pom to SCM. It takes care of the test case execution and does the final code commit to SCM. It carries out tagging of the code in the subversion. Finally, the version number is incremented and attached to the SNAPSHOT for other releases in the future by this plugin.
- mvn release: perform – It checks the code present in the repository and then runs Maven build goals to deploy the build artifact to the repository.
Finally, we need to run the below command for building the project:
mvn release: prepare
Once the successful completion of the build is done, run the following command:
mvn release: perform
Now the WAR file is uploaded to the repository.
Conclusion
We hope that major portions of Maven integration with Eclipse, its integration with TestNG, Maven profiles, dependency scope of Maven, and deployment automation of Maven should be comprehensible now. Also, we have discussed most of the scopes of the dependencies here.
For the Maven deployment process, we explored all the steps in-depth and explained some of the Maven release plugins. Read through the topics and gradually you will understand the real essence of using Maven in our work.
We shall continue with the series and gather knowledge on Maven Jenkins Integration, Maven interview questions, etc in our upcoming tutorials.
=> Check ALL Maven Tutorials Here.