- A
specific release of a project. Projects undergoing active development can
use a special identifier that marks a version as a SNAPSHOT.
Dependency –
- Dependency is an external JAR used in the
project.
- One of
the most basic uses of maven is to manage all the external JARs used in
the project, by adding them as dependencies in the POM.
If dependencies are not found in the local repo,
then maven downloads them from the Central Repo and puts them in the local
repo. [Local repo is just a folder containing all the jars, generally located
in the .m2 folder under each user's profile folder]
- Even if a maven dependency is not available in
the central repo, we can still put the dependency [jar] in the local repo
ourselves. To put the dependency manually, we need to adhere to the
groupId, artifactID and version format while creating the directory
structure.
<dependency>
<groupId>org.seleniumhq.selenium</groupId>
<artifactId>selenium-java</artifactId>
<version>2.46.0</version>
</dependency>
For the above dependency, the selenium jar needs to
be located under MAVEN_REPOSITORY_ROOT/org/seleniumhq/selenium/selenium-java/2.46.0/ This
can be done for jars which have a simple structure, but for jars with multiple
sub dir it can be tricky.
Maven reads the pom file, then downloads the dependencies into the local repo, then executes the lifecycle, build phases and goals via the plugins, as per the specified build profile.
An external dependency in Maven is a dependency (JAR file) which is not located in a Maven repository (neiterh local, central or remote repository). The word "external" thus means external to the Maven repository system - not just external to the project. Most dependencies are external to the project, but few are external to the repository system (not located in a repository) - these can be proprietory jars which are usually not free/OS. There 3 options to use such jars in the project.
Option 1: We can directly add such jars in the IDE and run our tests via testNG. We can keep such jars in the src/main/resources/lib folder and add their references in the project build path. Then these jars can be committed in the VCS and as such would be present along with the source code of the project. As such we can now run our tests via TestNG without any issues. But we cannot run like this on CI because these jars are not present in the POM, hence, we have to use option 2.
Option 2: Keep these jars in the src/main/resources/lib folder in the project. Then add their dependencies in the POM with dummy groupId, artifactID and version. But the path to these jars should always be relative to the src dir. We configure an external dependency like below:
<dependency>
<groupId>mydependency</groupId>
<artifactId>mydependency</artifactId>
<version>1.0</version>
<scope>system</scope>
<systemPath>${project.basedir}/src/main/resources/lib/mydependency.jar</systemPath>
</dependency>
Option 3: Use the maven-install-plugin or the maven-external-dependency-plugin.
- If a
project A depends on project B, which in turn depends on project C, then
we only have to include the dependency of project B in the pom of project
A - Maven takes care of child dependencies for project B [project
C] implicitly.
Also, there is an idea of dependency 'scope' for a
particular 'goal'. When a dependency has a scope of test, it will not be
available to the compile goal of the Compiler plugin, it would be available
only for the 'test'-esque goals. A
test-scoped dependency is a dependency that is available on the classpath only
during test compilation and test execution. If your project has war or ear
packaging, a test-scoped dependency would not be included in the project’s
output archive. To add a test-scoped dependency, add the dependency element to
your project’s dependencies section, as shown in the following example:
<dependency>
<groupId>org.apache.commons</groupId>
<artifactId>commons-io</artifactId>
<version>1.3.2</version>
<scope>test</scope>
</dependency>
SureFire plugin to run TestNG suite-
- Maven SureFire Plugin is a very widely used plugin to execute tests
- You
don’t have to do anything special to run a unit test; the test phase is a
normal part of the Maven lifecycle. You run Maven tests whenever you run
'mvn package' or 'mvn install' commands. If you would like to run all the
lifecycle phases up to and including the test phase, run 'mvn test'
command.
- When
Maven encounters a build failure, its default behavior is to stop the
current build. To continue building a project even when the Surefire plugin
encounters failed test cases, you’ll need to set the testFailureIgnore
configuration property of the Surefire plugin to true.
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<testFailureIgnore>true</testFailureIgnore>
</configuration>
</plugin>
</plugins>
</build>
This
property can also be set from the command line using the -D parameter:
mvn test -Dmaven.test.failure.ignore=true
Maven also provides for the ability to skip unit
tests using the skip parameter of the Surefire plugin. To skip tests from the
command line, simply add the maven.test.skip
property to any goal:
mvn install -Dmaven.test.skip=true
Another way to configure Maven to skip unit tests is
to add this configuration to your project’s pom.xml. To do this, you would
add a plugin element to your build configuration.
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<skip>true</skip>
</configuration>
</plugin>
</plugins>
</build>
- To have Maven run our tests in parallel, we need to run the tests as 'methods' and not 'classes', along with the fork count being equal to the runner methods, without re-using the threads/forks.
- If we run tests as 'classes', then they will not run in parallel. Basically, the way you define the execution config for TestNG, the same should be followed for SureFire also.
- Maven and its plugins use the TestNG Annotations to invoke the methods/classes as tests via SureFire plugin.
- Just add the below build tag in the pom before dependency tags to control how you build and run tests
