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


-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


 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





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

Java Archives (JAR) A JAR file encapsulates one or more Java classes, a manifest, and a descriptor. JAR files are the lowest level of archive. JAR files are used in J2EE for packaging EJBs and client-side Java Applications.

A WAR (Web Archive) is a module that gets loaded into a Web container of a Java Application Server. A Java Application Server has two containers (runtime environments) – one is a Web container and the other is a EJB container.

The Web container hosts Web applications based on JSP or the Servlets API – designed specifically for web request handling – so more of a request/response style of distributed computing. A Web container requires the Web module to be packaged as a WAR file – that is a special JAR file with a web.xml file in the WEB-INF folder.

An EJB container hosts Enterprise java beans based on the EJB API designed to provide extended business functionality such as declarative transactions, declarative method level security and multiprotocol support – so more of a RPC style of distributed computing. EJB containers require EJB modules to be packaged as JAR files – these have a ejb-jar.xml file in the META-INF folder.

Enterprise applications may consist of one or more modules that can either be Web modules (packaged as a WAR file) or EJB modules (packaged as a JAR file) or both of them. Enterprise applications are packaged as EAR files – these are special JAR files containing an application.xml file in the META-INF folder.

Basically EAR files are a superset containing WAR files and JAR files. Java Application Servers allow deployment of standalone web modules in a WAR file, though internally they create EAR files as a wrapper around WAR files. Standalone web containers such as Tomcat and Jetty do not support EAR files – these are not full fledged Application servers. Web applications in these containers are to be deployed as WAR files only.

In application servers – EAR files contain configurations such as application security role mapping, EJB reference mapping and context root url mapping of web modules.

Apart from Web modules and EJB modules EAR files can also contain connector modules packaged as RAR files and Client modules packaged as JAR files.

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

      <!--Enable snapshots for the built in central repo to direct -->
      <!--all requests to nexus via the mirror -->

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} -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
  -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



Specifying Version

      <!--Version should be 3.8.1-->

      <!--Version should less than or up to  3.8-->
      <!--Version should less than 3.8-->

      <!--Version should be between 3.1 to 3.8-->
      <!--If 3.8 is available it picks those-->

Specifying Scope

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

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

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

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

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


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


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.



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:


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.