This is caused by setting something too large on a 32-bit HotSpot vm, for example:If you have running the x86 JVM instead of the 64 bit you may end up with this issue

While running Maven Sure fire plugin you may endup with this problem mostly when you are using 32 bit version of Java

org.apache.maven.plugins
maven-surefire-plugin
2.7.2

-Xms1024m -Xmx1024m -XX:MaxPermSize=512m
 set "JAVA_OPTS=-Xms512m -Xmx512m -XX:MaxPermSize=512m


The MaxPermSize allowed is 512m, but it still throws error when you try to run a build setting to max of 512m.

Set MaxPermSize less than 500m

Solution

 set "JAVA_OPTS=-Xms512m -Xmx400m -XX:MaxPermSize=512m

This may also happen if maven is not using the right JVM if more that one JVM is installed in the system or set MAVEN_OPTS = -Xmx512m -XX:MaxPermSize=128m

parent-pom.xml

<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>3.8</version>
    </dependency>
 </dependencies>
</dependencyManagement>

child-pom.xml

<dependencies>
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
    </dependency>
 </dependencies>

Two Main Differeneces

  1. Dependency Management allows to consolidate and centralize the management of dependency versions without adding dependencies which are inherited by all children. This is especially useful when you have a set of projects (i.e. more than one) that inherits a common parent.Another extremely important use case of dependencyManagement is the control of versions of artifacts used in transitive dependencies.You still need to define them in the child POM to show that you are using them. They are not actually included in the child projects just because they are in in the parent POM. Enclosing dependencies in centralizes management of the version, scope, and exclusions for each dependency, if and when you decide to use it.
  2. Artifacts specified in the section <dependencies> will ALWAYS be included as a dependency of the child module(s).Artifacts specified in the section will only be included in the child module if they were also specified in the section of the child module itself. Why is it good you ask? because you specify the version and/or scope in the parent, and you can leave them out when specifying the dependencies in the child POM. This can help you use unified versions for dependencies for child modules, without specifying the version in each child module.

To sum up the above points in simple words in the parent-pom.xml if you are adding things inside tag then it would be available to the child-pom.xml. If you are adding the same thing within tag then you should manually add them to the child-pom.xml.In the child-pom.xml if the version is not specified it will take the parent-pom.xml version of the dependency as default else you can override them by specifying one in child-pom.xml

References Read It

Failure to find org.jfrog.maven.annomojo:maven-plugin-anno:jar:1.4.0 in http://myrepo:80/artifactory/repo was cached in the local repository, resolution will not be reattempted until the update interval of MyRepo has elapsed or updates are forced -> [Help 1]

The above statement tells that the artifact is cached in local repository.Now the artifact is not going to get downloaded unless it is

  1. It is forced to update from client Side
  2. Forcing from server side the expiration time

From Client Side 3 Solutions

  1. Using Maven Update to force update Snapshots(Mostly doesn’t work)
  2. Deleting the failed directory of Snapshot and forcing it to download
  3. By setting the Time interval for looking for Snapshot
    c:\Users\mugilvannan\maven\conf\settings.xml

    <profile>
      <id>nexus</id>
      <!--Enable snapshots for the built in central repo to direct -->
      <!--all requests to nexus via the mirror -->
      <repositories>
        <repository>
          <id>central</id>
          <url>http://central</url>
          <releases><enabled>true</enabled><updatePolicy>always</updatePolicy></releases>
          <snapshots><enabled>true</enabled><updatePolicy>always</updatePolicy></snapshots>
        </repository>
      </repositories>
     <pluginRepositories>
        <pluginRepository>
          <id>central</id>
          <url>http://central</url>
          <releases><enabled>true</enabled><updatePolicy>always</updatePolicy></releases>
          <snapshots><enabled>true</enabled><updatePolicy>always</updatePolicy></snapshots>
        </pluginRepository>
      </pluginRepositories>
    </profile>
    

There may be times direct access to JAR files are not allowed due to license restrictions.In such case declaring dependency in POM.xml has no effect. In such case the jar files should be manually downloaded and copied to maven local repository so while defining dependency in POM.xml it would take from mavens local repository

In Terminal

$ mvn install:install-file -Dfile={Path/ojdbc6.jar}
      -DgroupId=com.oracle -DartifactId=ojdbc6 -Dversion=11.2.0 -Dpackaging=jar

In my case I have downloaded the file to Downloads Directory

 mvn install:install-file -Dfile=C:\\Downloads\\ojdbc14.jar
           -DgroupId=com.oracle -DartifactId=ojdbc7 -Dversion=12.1.0 -Dpackaging=jar

On executing the above command it would be copied to maven .m2 local repository

Now the above will add the file to maven local repository.This should be followed by definition in pom.xml for dependency

<dependencies>  

  	<dependency>
            <groupId>com.oracle</groupId>
            <artifactId>ojdbc14</artifactId>
            <version>12.1.0</version>
        </dependency>
   </dependencies>
<dependencies>
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>3.8.1</version>
      <scope>test</scope>
    </dependency>
  </dependencies>

Specifying Version

      <!--Version should be 3.8.1-->
      <version>3.8.1</version>

      <!--Version should less than or up to  3.8-->
      <version>[,3.8]</version>
      
      <!--Version should less than 3.8-->
      <version>[,3.8)</version>

      <!--Version should be between 3.1 to 3.8-->
      <!--If 3.8 is available it picks those-->
      <version>[3.1,3.8]</version>

Specifying Scope


<!--Jar file would be available to JUnit Test Folder-->
<scope>test</scope>

<!--available as Part of Web Server i.e tools.jar-->
<scope>provided</scope>

<!--Jar File available only during runtime-->
<!--Use of Interface at Compile Time and actual class at runtime-->
<scope>runtime</scope>

<!--Use of Interface at Compile Time and actual class at runtime-->
<scope>runtime</scope>

Defines the Maven Plugin with which the compilation has to be carried out

<plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-compiler-plugin</artifactId>
        <version>3.6.1</version>
        <configuration>
          <source>1.8</source>
          <target>1.8</target>
        </configuration>
      </plugin>
    </plugins>

Effective POM
Tells the Details of Super POM.xml Lists default configuration.

.
.
<build>
    <sourceDirectory>D:\java\TestMvnProj2\src\main\java</sourceDirectory>
    <testSourceDirectory>D:\java\TestMvnProj2\src\test\java</testSourceDirectory>
    <outputDirectory>D:\java\TestMvnProj2\target\classes</outputDirectory>
</build>
.
.

The above XML code specify the details of sourceDirectory, outputDirectory

You can also see list of plugins called at different phases of maven life cycle.

Parent POM
List of Child Projects are added into modules as separate module.

.
.
<packaging>pom</packaging>

<modules>
<module>Service</module>
<module>Controller</module>
<module>Model</module>
</modules>
.
.

Basic Paradigms

What is POM.xml
A Project Object Model or POM is the fundamental unit of work in Maven. It is an XML file that contains information about the project and configuration details used by Maven to build the project. It contains default values for most projects. Examples for this is the build directory, which is target. Super POM is Mavens default POM. All POMs extend the Super POM unless explicitly set

What is a Maven artifact?
groupId – Package Name
artifactId – Project Name

An artifact in maven is a resource generated by a maven project. Each maven project can have exactly one artifact like a jar, war, ear, etc.Each maven project has a unique identifier consiting of [groupId, artifactId, version]. When a maven project requires resources of another project a dependency is configured in it’s pom.xml using the above-mentioned identifier. Maven then automatically resolves the dependencies when a build is triggered. The artifacts of the required projects are then loaded either from the local repository, which is a simple directory in your user’s home, or from other (remote) repositories specified in you pom.xml.

Now the once mvn install is done the same snapshots are available in repository location as below

A snapshot version in Maven is one that has not been released.

The idea is that before a 1.0 release (or any other release) is done, there exists a 1.0-SNAPSHOT. That version is what might become 1.0. It’s basically “1.0 under development”. This might be close to a real 1.0 release, or pretty far (right after the 0.9 release, for example).

The difference between a “real” version and a snapshot version is that snapshots might get updates. That means that downloading 1.0-SNAPSHOT today might give a different file than downloading it yesterday or tomorrow.

Usually, snapshot dependencies should only exist during development and no released version (i.e. no non-snapshot) should have a dependency on a snapshot version.

The snapshot is not necessarily more stable: it is just the latest build. The snapshot precedes the actual release, it does not come after it. Indeed, version numbers typically do not refer to branches

When you build an application, Maven will search for dependencies in the local repository. If a stable version is not found there, it will search the remote repositories (defined in settings.xml or pom.xml) to retrieve this dependency. Then, it will copy it into the local repository, to make it available for the next builds.

For example, a foo-1.0.jar library is considered as a stable version, and if Maven finds it in the local repository, it will use this one for the current build.

Now, if you need a foo-1.0-SNAPSHOT.jar library, Maven will know that this version is not stable and is subject to changes. That’s why Maven will try to find a newer version in the remote repositories, even if a version of this library is found on the local repository. However, this check is made only once per day. That means that if you have a foo-1.0-20110506.110000-1.jar (i.e. this library has been generated on 2011/05/06 at 11:00:00) in your local repository, and if you run the Maven build again the same day, Maven will not check the repositories for a newer version.

Maven provides you a way to can change this update policy in your repository definition:

<repository>
    <id>foo-repository</id>
    <url>...</url>
    <snapshots>
        <enabled>true</enabled>
        <updatePolicy>XXX</updatePolicy>
    </snapshots>
</repository>

where XXX can be:

always – Maven will check for a newer version on every build;
daily – the default value;
interval:XXX – an interval in minutes (XXX)
never – Maven will never try to retrieve another version. It will do that only if it doesn’t exist locally. With the configuration, SNAPSHOT version will be handled as the stable libraries.

Updating Maven Snapshots are helpful during development where the maven first looks for local version of snapshot and adds to working set but still we get a build error we can force update snapshots which gets the snapshots from the repository

What is difference between Eclipse Project -> Clean and mvn clean?

Eclipse project clean is only clearing out the folders that are set as output folder in the project’s preferences.It Deletes previously generated Eclipse files (like .project and .classpath and .settings) and then generates new ones, thus, effectively updating them.

It may be useful if you introduced some changes in pom.xml

mvn clean command deletes target directory and then builds all you code and
installs artifacts into local repository.

What Maven update Project Does?

It syncs the Eclipse project settings with that of the pom. If you for example change important plugin settings, such as the output java version, you will find that Eclipse will ask you to update the project and afterwards the configured Java runtime in the project will have changed to reflect what your Maven pom indicates.

  1. That is an important thing to keep in mind: the Maven pom is the lead in this kind of project setup. If you want settings to change, try to do that through the pom and not through Eclipse project settings directly or doing a project update might revert what you have changed. There are usually some things I have to correct myself anyway though, such as build path exclusions that m2eclipse likes to put in and strange deployment assembly configurations.
  2. Update Project also provides more options such as Force Update of Snapshots / Releases which is extremely helpful when you have dependencies that are looking for the latest. (e.g.: [1.0) will find 1.0.* – whatever’s the latest.)

Two types of Maven dependencies
Direct: These are dependencies defined in your pom.xml file under the section.
Transitive: These are dependencies that are dependencies of your direct dependencies.

What are dependencies with provided scope meant to?
Either be excluded from the final artifact (for example, for war files you would not want to include servlet-api, servlet-jsp, etc) since the server itself has the servlet related jar files

Difference Between Update Snapshots and Update Dependency
By default Maven is supposed to update snapshots once a day.Specific dependency is determined using group, name and version. These attributes can be identical for two different snapshots. Maven uses the latest snapshot based on internal time stamp.

what is the difference between classpath and build path?
The classpath is the conventional way to tell the Java compiler and the Java runtime where to find compiled classes.The class path is used at runtime to load compiled classes and resources.

The build path is used for building your application. It contains all of your source files and all Java libraries that are required to compile the application.The IDE uses this to figure out the classpath and sourcepath for compiling the Java code.The build path is used at compile time to find the dependencies needed to build your project.

For example, an Eclipse build path for a project includes the other projects that it depends on, and lists any additional library JARs that the project contains / relies on. It also lists the packages in the current project that downstream projects can depend on.

If you are using Maven for your project, the IDE buildpath mechanism is secondary to the dependencies declared in the POM files. For example, using Eclipse with the m2eclipse, the buildpath is synthesized from the POM files.

What is .project and .classpath files in Eclipse
The .project file is maintained by the core Eclipse platform, and its goal is to describe the project from a generic, plugin-independent Eclipse view.When a project is created in the workspace, a project description file is automatically generated that describes the project. The sole purpose of this file is to make the project self-describing, so that a project that is zipped up or released to a server can be correctly recreated in another workspace.

.classpath Classpath specifies which Java source files and resource files in a project are considered by the Java builder and specifies how to find types outside of the project. The Java builder compiles the Java source files into the output folder and also copies the resources into it.

what mvn eclipse:eclipse does
Sometimes the dependencies don’t update even with Maven->Update Project->Force Update option checked using m2eclipse plugin.

mvn eclipse:eclipse

This will update your .classpath file with the new dependencies while preserving your .project settings and other eclipse config files.

If you want to clear your old settings use


mvn eclipse:clean
mvn eclipse:eclipse

mvn eclipse:clean will erase your old settings, then mvn eclipse:eclipse will create new .project, .classpath and other eclipse config files

What is Maven artifact?
An artifact is a file, usually a JAR, that gets deployed to a Maven repository.

Maven is based around the central concept of a build lifecycle.
There are three built-in build lifecycles

There are three lifecycle phases in maven

  1. clean
  2. build (default)
  3. site

You can Either trigger a phase or goal in maven

When the clean lifecycle is called it has three phases internally.For example, the clean life cycle has 3 phases (pre-clean, clean, post-clean).

For example the default lifecycle comprises of the following Build Phases:

◾validate – validate the project is correct and all necessary information is available
◾compile – compile the source code of the project
◾test – test the compiled source code using a suitable unit testing framework. These tests should not require the code be packaged or deployed
◾package – take the compiled code and package it in its distributable format, such as a JAR.
◾integration-test – process and deploy the package if necessary into an environment where integration tests can be run
◾verify – run any checks to verify the package is valid and meets quality criteria
◾install – install the package into the local repository, for use as a dependency in other projects locally
◾deploy – done in an integration or release environment, copies the final package to the remote repository for sharing with other developers and projects.

So to go through the above phases, we just have to call one command:

>> mvn

i.e

>> mvn install

For the above command, starting from the first phase, all the phases are executed sequentially till the ‘install’ phase. A command can be used in a multi-module scenario mvn clean install.

A Build Phase is Made Up of Plugin Goals
Most of Maven’s functionality is in plugins. A plugin provides a set of goals that can be executed using the following syntax:

mvn [plugin-name]:[goal-name]

For example, a Java project can be compiled with the compiler-plugin’s compile-goal by running mvn compiler:compile

Build lifecycle is a list of named phases that can be used to give order to goal execution.

Goals provided by plugins can be associated with different phases of the lifecycle

mvn test

When the preceding command is executed, Maven runs all goals associated with each of the phases up to and including the test phase. In such a case, Maven runs the resources:resources goal associated with the process-resources phase, then compiler:compile, and so on until it finally runs the surefire:test goal.

A goal not bound to any build phase could be executed outside of the build lifecycle by direct invocation. The order of execution depends on the order in which the goal(s) and the build phase(s) are invoked. For example, consider the command below. The clean and package arguments are build phases, while the dependency:copy-dependencies is a goal (of a plugin).

mvn clean dependency:copy-dependencies package

If this were to be executed, the clean phase will be executed first (meaning it will run all preceding phases of the clean lifecycle, plus the clean phase itself), and then the dependency:copy-dependencies goal, before finally executing the package phase (and all its preceding build phases of the default lifecycle).

Furthermore, a build phase can also have zero or more goals bound to it. If a build phase has no goals bound to it, that build phase will not execute. But if it has one or more goals bound to it, it will execute all those goals.

The image showing various plugins goals used for different phase during execution.To take the other way round plugins executing goals at different phases.