Category Archives: Maven

What are Maven Snapshots

Posted on by

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

Maven Interview Questions

Posted on by

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 lifecycle

Posted on by

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.

What is maven?what it does?

Posted on by

Maven is a “build management framework”

You could define how your .java files get compiled to .class, packaged into .jar (or .war or .ear) files, (pre/post)processed with tools, managing your CLASSPATH, and all others sorts of tasks that are required to build your project.

 Though it doesn’t give fine grain control like  Apache Ant or Gradle or Makefiles in C/C++, but it attempts to be completely self-contained in it that you shouldn’t need any additional tools or scripts by incorporating other common tasks like downloading & installing necessary libraries etc.

It is also designed to around “build portability” so that you don’t get issues as having the same code with the same buildscript working on one computer but not on another one (this is a known issue, we have VMs of Windows 98 machines since we couldn’t get some of our Delphi applications compiling anywhere else). Because of this, it is also the best way to work on a project between people who use different IDEs since IDE-generated Ant scripts are hard to import into other IDEs, but all IDEs nowadays understand and support Maven.

There are few inflexibility in maven and some developers stick with Ant or similar, but a growing number of them are people who have moved on to Maven successors such as Gradle and Buildr. These successors inherit from Maven the idea of providing a powerful set of build steps out of the box, but make it immensely easier to add custom steps too.