Limited Time Offer!

For Less Than the Cost of a Starbucks Coffee, Access All DevOpsSchool Videos on YouTube Unlimitedly.
Master DevOps, SRE, DevSecOps Skills!

Enroll Now

Difference between Maven 1 and Maven 2

What is Maven 2?
Maven 2.0 is a complete rewrite of the ‘original’ Maven application (‘Maven 1’). As such, it is very different from Maven 1, and not backwards-compatible (eg, it cannot execute Maven 1 plugins). However, Maven 2.0 is the latest stable release of the Maven application, and new users are generally encouraged to use it for all new projects.
If you are familiar with Maven 1, you can find some information about moving to Maven 2 here or on the main Maven site.
Maven 1
To access the repository from your project, add the following line to your project.properties or build.properties.
maven.repo.remote=http://download.java.net/maven/1/,http://www.ibiblio.org/maven/
Maven 2
For Maven2, one needs to add the following into a project’s pom.xml, or into conf/settings.xml <settings>/<profiles>/<repositories> (NOT in mirrors/mirror) where Maven2 is installed:

<repository>
<id>java.net</id>
<url>http://download.java.net/maven/1</url>;
<layout>legacy</layout>
</repository>

Maven 2 Lifecycles

Lifecycles are groupings of goals that define a process for building a project. Goals are bound to lifecycles to define a sequence that must be accomplished to produce results. Lifecycles ensure that users building projects with Maven only need to learn a small set of commands. Whereas Maven defines a default set of goals for each typical lifecycle, developers can bind additional goals to lifecycles to transparently add functionality to a build.
Typical lifecycles include:

  • compile—compile the source code
  • test—unit test the compiled source.

Note: Unit tests should not require the classes to be packaged or deployed.

  • package—bundle the compile and tested source code into a distributable package, such as a jar or war.
  • integration-test—employ the package as necessary and run integration tests.
  • install—install the package into the local repository. This allows the package to be utilized as a dependency of other projects.
  • deploy—copies the final package into the remote repositories for sharing and use with other projects.

As you can see, each lifecycle depends upon and builds upon the next. As a result, when a goal is bound to the compile lifecycle, all lifecycles will ensure its execution.
Lifecycles can be executed in conjunction with standalone goals. For instance, commonly the clean:clean goal is executed before the install goal. This is done by invoking:

m2 clean:clean install

Native Multiproject Support

One of the best practices that Maven strongly encourages is the idea that a single project should result in a single artifact, or package, being created. This best practice results in simplified builds and organized project structures. By natively supporting a hierarchical structure of projects, Maven now makes developing enterprise projects which implement this approach easier.
Maven 1 included a plugin for working with related of projects—or multiprojects. Maven 2 takes multiproject builds a step further by including a specialized parent descriptor and native multiproject execution support. As a result, any goals or lifecycles invoked upon a multiproject POM will result in each subproject goal being achieved.

Other Enhancements

Several other changes are included in Maven 2. Maven has been rewritten to be smaller and faster. The architectural changes make embedding Maven into other tools easier and allows for faster command line execution. Maven 2 depends upon fewer dependencies, resulting in a smaller distribution.
The way extensions are made to Maven has been changed in Maven 2. Instead, developers are encouraged to utilize JavaBeans for enhancements. Whereas scripting is allowed (through marmalade support—which includes a jelly facade), it is no longer the tool of choice. All extensions are made through the development of plugins (projects can no longer be customized through scripting in the maven.xml).
The introduction of a settings.xml file replaces the need for properties files. The settings file can be defined at a system, user, or project level. Settings are used to define private configuration information, including usernames and passwords. Project properties (including plugin configuration) are now all defined in the pom.xml.

Understanding Maven 2 Project Types

The first step to creating a maven project is determining which project template, or archetype, your Maven project should be configured as. Archetypes define which type of artifact will be produced by a project. Several archetype templates exist. The standard archetype will produce a standard library jar file. Templates also exist for webapps/wars, Maven plugin projects, documentation Web sites, and more.

Creating Project Descriptors

The archetype:create goal can be utilized to create a basic pom.xml for you project. This basic POM will allow you to execute all of the lifecycles and goals associated with any maven project. The archetype:create goal should be executed as follows:

m2 archetype:create -DgroupdId=com.daviddewolf.maven -DartifactId=example

This simple command creates the basic infrastructure needed for a project. It creates the pom.xml as well as the basic directory structure of for both source and test code. The following structure indicates the directories and files produced by issuing the archetype:goal command as listed above.

+ root
  - pom.xml
  + src
    + main
      + java
        + com
          + daviddewolf
            + maven
              + example
                - App.java
    + test
      + java
        + com
          + daviddewolf
            + maven
              + example
                - TestApp.java

This simple structure that is created is enough to get started with Maven. All of the lifecycles now can be utilized. A simple invocation of the install lifecycle will compile, test, and package the application and then deploy it to the local system repository for use by other projects.
Once created, the POM can be customized to meet the requirements of the specific project. Documentation on the Maven POM can be found on the Maven2 Web site.

Goals You Should Know About

The introduction of lifecycles in Maven 2 has greatly reduced the number of goals that a developer must be aware of. Still, the following goals will undoubtedly be found useful (and can be utilized as soon as the basic descriptor has been generated).

  • clean:clean Clean all artifacts and intermediary files created by Maven
  • idea:idea Generate project files for the IntelliJ IDEA IDE
  • eclipse:eclipse Generate project files for the Eclipse IDE
  • javadoc:javadoc Generate the javadocs for the project
  • antrun:run Run a specified ant target
  • clover:clover Generate a coverage report for the project
  • checkstyle:checkstyle Generate a checkstyle report for the project
  • site:site Generate a documentation Web site for the project. This site will include many information reports concerning the project.

For more information concerning these and other goals, see the Maven2 Web site.
Conclusions
Learning Maven is not difficult; it simply requires a willingness to accept a new philosophy for building applications. Maven utilizes a a centralized project descriptor to intelligently build applications with prebuilt build tools. This differs greatly from ant and other build tools in that project developers are no longer required to write build systems by using a comprehensive set of utilities. This change will save development teams significant time and has started a revolution in build tools.
It is important to remember that Maven2 is still currently only released as Beta Software. Although it is mature enough to utilize in most projects, all of the Maven 1 plugins have not yet been migrated to Maven 2. With time, Maven 2 will become more widely accepted and the number of available plugins will grow beyond what is even available in Maven 1.
Reference:
http://www.developer.com/open/print.php/10930_3552026_2
http://www.sonatype.com/books/maven-book/reference/installation-sect-upgrade-detail.html

Tagged : / / / / /

Writing a Custom Plugin for Maven

Introduction

In this article, we will learn about Maven which is a project management framework that provides a configurable approach for managing software projects. Maven covers all the necessary phases that happen right from project creation, building, documentation, reporting, installation and deployment. This article begins with the basics of Maven along with the concepts like Project Object Model (aka POM), the various life-cycles in Maven etc. Then it continues with using Maven for creating a project till installation of the project in a local repository. The latter part of the article provides details about creating custom Maven plugins that can be executed in stand-alone mode as well as part of some Maven life-cycle.

Maven Custom Plug-In (Example Code)

Maven Concepts

In this section, we will see the basics of Maven concepts like Project Object Model, the standard lifecycles available in Maven as well as the dependency scope that comes up while dealing with dependency with projects.

Project Object Model

Project information, its dependencies and the artifacts that can be built are described in POM which is essentially a configuration file in XML. POM basically contains instructions on what needs to be done during the various life-cycles that happen during a build. Note that the POM is not coupled to java projects, in fact the project can be written in any language like C, C# etc. For example, consider the sample minimal POM,

 

<project>

    <modelVersion>4.0.0</modelVersion>

    <name>adder</name>
    <url>http://www.javabeat.net/adder</url>
    <groupId>net.javabeat.adder</groupId>
    <artifactId>adder</artifactId>
    <version>1.0-SNAPSHOT</version>
    <packaging>jar</packaging>

    <dependencies>
        <dependency>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
            <version>3.8.1</version>
            <scope>test</scope>
        </dependency>
    </dependencies>

</project>

Have a look at the above POM. It defines the information about the project and its dependant projects. We will look into more details about the various POM elements.

 

  • modelVersion – This defines the version of the POM.
  • name – The name of the project.
  • groupId – This identifies the group (or the organization) that created the project. This property usually takes the domain address which represents the group or the organization so that uniqueness is maintained across the groups.
  • artifactId – This identifies the artifact (output component) name that comes from a project. Artifacts can be anything like a JAR, WAR, EAR etc
  • version – This property identifies the version of the artifact. Usually the version takes the format as “majorVersion.minorVersion-qualifier”. For example, “1.1-alpha”, “1.2-beta”, “1.3-SNAPSHOT”. packaging – Represents the type of artifact, for example – jar, war, ear etc.

In the next section in the POM, we have included the dependencies of the project. Note that this section is optional. If there are no dependencies for a project (which is unlikely the case), this can be omitted. However, in this example case, we have declared a dependency to junit and it is expected that the project will contain some test resources. It is always a good idea to define the version of the artifact while defining a dependency, so that during runtime, we are not facing any issues because of version match. We have mentioned the scope as test, more details about this element will follow in the forthcoming section.

Dependency Scope

A project can depend on a number of dependent projects and Maven provides a way for defining the dependencies among projects through configuration. One can control the level of dependency through scope and the default being ‘compile’. The following scopes are available.

 

  • Compile – This being the default scope will be available at the classpath during the compilation as well as during runtime.
  • Runtime – The presence of this scope ensures that the dependency will be available at the runtime and not during the compile-time. For example, one may use the Servlet API during the compilation phase, however the Servlet implementation (from Sun, Oracle, IBM etc) will be required during the runtime only.
  • Test – This scope ensures that the dependency is available during the compilation of the test resources as well as during the execution of the test resources.
  • Provided – This dependency is mostly used while developing J2EE applications where the dependency is available as part of the J2EE container (or any Container) and it is not necessary for the project to package the dependency as part of the artifact. For example, while developing Enterprise bean applications, as part of the project, we will be using EJB jar for compilation; however, we never package this jar as part of the project because the EJB container will provide this jar.

Build Life-cycle

life-cycle defines the execution for achieving a set of goals. Each life-cycle defines a sequence of phases for achieving the goals. The

Maven Custom Plug-In (Example Code)

Using Maven

In this section, we will see how to use maven for creating, compiling, building, packaging and installing a project. Download the latest version of Maven from here. Installation of maven will be as simple as un-zipping the downloaded file into a desired directory. In this example, we will be seeing the usage of various maven plugins and goals that contributes to the entire project life-cycle. Before proceeding with the sample, create an environment variable MAVEN_HOME that points to the Maven installation directory and ensure that the PATH variable contains %MAVEN_HOME/bin.

Creating a project

Execute the following command which is used to create the initial project structure.

 

mvn archetype:create -DgroupId=net.javabeat.emailservice -DartifactId=emailservice

Note that in archetype:createarchetype represents the plugin prefix and create represents the goal. This goalcreates a project with the name emailservice. As soon as this command is executed, one can see a directory called emailservice which has the src folder for holding the main java files, along with java files representing test-cases. The POM file with the name pom.file will also be created with the structure as follows,

pom.xml

<project>
    <modelVersion>4.0.0</modelVersion>

    <groupId>net.javabeat.emailservice</groupId>
    <artifactId>emailservice</artifactId>
    <version>1.0-SNAPSHOT</version>
    <packaging>jar</packaging>

    <name>emailservice</name>
    <url>http://maven.apache.org</url>

    <dependencies>
        <dependency>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
            <version>3.8.1</version>
            <scope>test</scope>
        </dependency>
    </dependencies>

</project>

Importing the project in Eclipse

This step is optional for those who are not working with Eclipse being the IDE for developing the project. Change the current directory to emailservice and issue the following command. This goal eclipse creates the project metadata files that are complaint with Eclipse. As soon as the following goal is executed there will be two files generated in the current directory which are .project and .classpath. This is for Eclipse to understand so that the newly created project can be imported in Eclipse IDE to work with.

 

mvn eclipse:eclipse

Now, for importing the project into Eclipse, Open Eclipse, go to File -> Import -> Existing Projects into Workspace and navigate to the directory containing the .project and .classpath files and Click OK. Now this project gets imported into Eclipse workspace.

Adding files to project

To make the project meaningful, we will add the following files into the main source folder.

EMail.java

package net.javabeat.emailservice;

public class EMail {

    private String fromAddress;
    private String toAddress;
    private String subject;
    private String message;
    private String status;

    public String getFromAddress() {
        return fromAddress;
    }

    public void setFromAddress(String fromAddress) {
        this.fromAddress = fromAddress;
    }

    public String getToAddress() {
        return toAddress;
    }

    public void setToAddress(String toAddress) {
        this.toAddress = toAddress;
    }

    public String getSubject() {
        return subject;
    }

    public void setSubject(String subject) {
        this.subject = subject;
    }

    public String getMessage() {
        return message;
    }

    public void setMessage(String message) {
        this.message = message;
    }

    public String getStatus() {
        return status;
    }

    public void setStatus(String status) {
        this.status = status;
    }		
}

The above class represents the Email model object that will be used by EmailService class for sending email. Given below is the code listing for EMailService class.

EMailService.java

package net.javabeat.emailservice;

public class EMailService {

    public EMail sendEmail(String fromAddress, String toAddress, String subject, String message){

        EMail emailObject = new EMail();
        emailObject.setFromAddress(fromAddress);
        emailObject.setToAddress(toAddress);
        emailObject.setSubject(subject);
        emailObject.setMessage(message);
        emailObject.setStatus("SUCCESS");

        System.out.println("Sending email from " + fromAddress + " to " + toAddress + "with subject "
		    + subject + " having the message contents " + message);
        return emailObject;
    }

In this section we will see how to write custom maven plugins. It is possible that the custom maven can be made to run outside the standard life-cycle phase or it can be made to be executed as part of the standard life-cycle phase. We will see how to accomplish both of these items in the following sections.

Creating standalone plugins

In this section, we will write a custom plugin and will see how to write it in stand-alone mode – i.e running the plugin directly without establishing any dependencies on any of the standard life-cycles available in Maven.

Creating the project

The first step is to create the project containing the custom maven plugin. This project is quite different from the regular java project because it is not a regular java artifact like JAR, WAR etc. Instead it is going to be a maven plugin. Issue the following command to create the maven plugin project.

 

mvn archetype:create -DgroupId=net.javabeat.maven -DartifactId=environment-info -DarchetypeArtifactId=maven-archetype-mojo

The above command creates a project with the name environment-info with the standard directory layout containing the source and test resources. If you look into the POM file, the package type will be maven-plugin to indicate that this is a maven plugin project.

Importing the project into Eclipse

This step is optional and this is for someone who wishes to work with the project in Eclipse IDE. Issuing the following with the current directory being environment-info creates the Eclipse .project and .classpath files. Now, open Eclipse and go to File -> Import -> Existing Project into Workspace and specify the directory to <<path to environment-info>> directory.

 

mvn eclipse:eclipse

Creating the plugin

In Maven, the plugin that achieves a specific task is called by the name MOJO (Maven Old Java Object similar to POJO). A MOJO defines the goal which is nothing but the custom action which is executed upon user’s request. In this example, we will see a custom MOJO that will define the goal of storing all the environmental properties in a text file upon execution. Have a look at the following code,

EnvironmentInfoTask.java

package net.javabeat.maven; import java.io.BufferedWriter; import java.io.File; import java.io.FileWriter; import java.util.Iterator; import java.util.Map; import org.apache.maven.plugin.AbstractMojo; import org.apache.maven.plugin.MojoExecutionException; import org.apache.maven.plugin.MojoFailureException; /** * @goal env-info */ public class EnvironmentInfoTask extends AbstractMojo{ /** * @parameter * default-value="log.txt" * expression="${environment.filename}" */ private String fileName; /** * @parameter * default-value="C:\\temp" * expression="${environment.base_dir}" */ private File baseDirectory; /** * @parameter * default-value="true" * expression="${environment.loggingRequired}" */ private boolean loggingRequired; public void execute() throws MojoExecutionException, MojoFailureException { StringBuilder fileContents = new StringBuilder(); if (baseDirectory.exists()){ baseDirectory.mkdirs(); log("Created base directory '" + baseDirectory.getAbsolutePath() + "'"); } Map<String, String> environment = System.getenv(); Iterator<Map.Entry<String, String>> entries = environment.entrySet().iterator(); fileContents.append("Environment Information:" + newLine()); fileContents.append("-----------------------------------------------------------" + newLine()); while (entries.hasNext()){ Map.Entry<String, String> entry = entries.next(); fileContents.append(entry.getKey() + "------------->" + entry.getValue() + newLine()); } fileContents.append("-----------------------------------------------------------" + newLine()); writeToFile(fileContents); log("File contents written"); } private void log(String message){ if (loggingRequired){ System.out.println(message); } } private static String newLine(){ return System.getProperty("line.separator"); } private void writeToFile(StringBuilder fileContents){ FileWriter fWriter = null; BufferedWriter bWriter = null; try{ fWriter = new FileWriter(baseDirectory + File.separator + fileName); bWriter = new BufferedWriter(fWriter); bWriter.write(fileContents.toString()); }catch (Exception e){ log("Error in writing the contents to file ->" + e.getMessage()); }finally{ try{ if (bWriter != null){ bWriter.close(); } if (fWriter != null){ fWriter.close(); } }catch (Exception e){ log("Error in closing the resources ->" + e.getMessage()); } } } }

The first thing to notice is the class EnvironmentInfoTask which is going to persist the environmental information into a file extends AbstractMojo class which in turn extends the Mojo interface. Note that the goal for this MOJO is annotated using XDoclet using goal attribute with the name env-info. The method that will be called during execution of the MOJO is execute(). This method does the job of persisting the environmental properties by taking information from the various properties .

 

  • Base Directory – the directory under which the log file name will be created which is of type ‘java.io.File’. Note that we have used XDoclet ‘parameter’ for annotating this property. This property has the default value ‘C:\\temp’ which means the this is the default location for the log file. However, this value can be overridden at runtime by specifying the property ‘environment.base_dir’ which is an expression and its value will be resolved at runtime
  • Filename – the name of the log file into which the environmental properties will be written. Note that the default value for the log file name is ‘log.txt’. However, during runtime, the value can be overridden through the property ‘environment.filename’
  • Logging Required – whether logging information on what this MOJO is doing has to be shown. The default value being true can be overridden by specifying the value false to the property ‘environment.loggingRequired’.

Compiling the project

Issue the following command for compiling the maven plugin project.

 

mvn compile

Packaging the project

The following command is used to package the plugin project.

 

mvn package

Installing the project

For installing the project into the local Maven repository, issue the following command.

 

mvn install

Usually, on Windows, the local repository is %USER_HOME%/.m2/repository. On Windows XP, USER_HOME will expand to "C:\\Document and Settings\\<<UserName>>", however in Windows Vista it is "C:\\Users\\<<UserName>>".

Running the project

There are several ways to run the maven plugin. We will see them one by one. Generally running a Maven plugin takes the following form,

 

mvn groupId:artifactId:version:goalName

In our case, the group id is net.javabeat.maven, artifact id is environment-info, version is 1.0-SNAPSHOT and goal name is env-info. So running the following command will run the custom plugin

 

mvn net.javabeat.maven:environment-info:1.0-SNAPSHOT:env-info

Running the above command will create a directory C:\\temp (if not present) and create a file name with log.txt with the environment information. Because logging is enabled by default, the text ‘Created base directory C:\temp‘ and ‘File contents are written’ will be displayed in the console.

It is also possible to configure the plugin by passing alternate input values. Have a look at the following command. This command specifies an alternate base directory C:\\temp-new for the log file newLog.txt with logging turned off. Note that for passing a property to a plugin the standard way is –DpropertyName=propertyValue.

 

mvn net.javabeat.maven:environment-info:1.0-SNAPSHOT:env-info -Denvironment.base_dir=C:\temp-new -Denvironment.filename=newLog.txt -Denvironment.loggingRequired=false

It is also possible to omit the version information while running the plugin in which case, Maven tries to find the recent version for the plugin by comparing the version strings. In our case, this wouldn’t happen, because we have only one version which is 1.0-SNAPSHOT. So the following command will also work.

 

mvn net.javabeat.maven:environment-info:env-info

Another approach to run the plugin is by omitting the group id and just specifying the artifact id along with the goal name. However, for this to happen, we have to add the group id to the default list of groups that Maven will look for. Open the file %MAVEN_HOME%/conf/settings.xml and add the following line under the element pluginsGroup.

 

<pluginGroup>net.javabeat.maven</pluginGroup>

This ensures that we have added the group net.javabeat.maven to the list of default groups that Maven will search for, because of which the following command will work.

 

mvn environment-info:env-info

Attaching plugins to existing life-cycle

So far, we have seen how to run a custom plugin in stand-alone mode. This is not of much-use and Maven provides a way for binding the goals of any custom plugin into existing build cycle. For example, let us consider that we have written a custom plugin which will simply print the current date and we want this plugin to be executed during the compilation phase and the installation phase of a project. We will see how to accomplish this goal in this section.

The following listing shows the custom plugin which will simply emit the date information.

DateInfo.java

package net.javabeat.maven; import java.util.Date; import org.apache.maven.plugin.AbstractMojo; import org.apache.maven.plugin.MojoExecutionException; import org.apache.maven.plugin.MojoFailureException; /** * @goal date-info */ public class DateInfo extends AbstractMojo { public void execute() throws MojoExecutionException, MojoFailureException { Date currentDate = new Date(); getLog().info("Current date is " + currentDate); } }

Follow the same process of creating the project, then creating the plugin, compilation, packaging and installation as we have discussed before. We will see how to attach this custom plugin during the compile and the install phase. Open POM.xml file and add the following after the project dependencies element,

 

<build> <plugins> <plugin> <groupId>net.javabeat.maven</groupId> <artifactId>environment-info</artifactId> <version>1.0-SNAPSHOT</version> <executions> <execution> <id>date-info-compile</id> <phase>compile</phase> <goals> <goal>date-info</goal> </goals> </execution> <execution> <id>date-info-install</id> <phase>install</phase> <goals> <goal>date-info</goal> </goals> </execution> </executions> </plugin> </plugins> </build>

Though the above XML fragment is big, it is fairly simple. First thing is, it defines the execution element where we can define goals for executions. We have defined two execution elements one for the compile phase and the other for the install phase and we have given appropriate id for each execution element. Have a note at the goals section. We have included our custom goal date-info which will display the current date information. Note that where to search for the goal’s group id and the artifact id along with optional version is defined just above the executions element.

After this whenever we run mvn compile and mvn install for any project that contains the above definition we will see that the goal date-info getting invoked during the phases.

Conclusion

In this article, we have seen how to use Maven for creating projects and to manage dependencies between projects. We have seen Maven simplifying the task of creating, compiling, packaging, installing projects thereby reducing the pain from developers and build managers. Also discussed in the article are the extension capabilities provided by Maven for pluging-in custom plugins in the form of MOJOs.

}

Note that there is no real functionality in the above, all it does is to accept the various user inputs and constructs an email object before returning it.

Compiling the project

The next step is to compile to project, by default the compilation process will create a folder called target and it will place the java class files along with any resource files, if present.

 

mvn compile

Note that the location of the target folder as well as the location of the target folder is also configurable.

Packaging the project

This step will package the project with the packaging type mentioned in POM, which is JAR. Before packaging it will also execute the test cases (if specified) in the test folder and the packaged jar will be placed in the target folder.

 

mvn package

Installing the project

The final step is to install the jar in a local repository so that other projects, if they are dependant on this project can make references to this project. The following command will install (i.e copy the jar) to the local repository.

 

mvn install

Note that, by default, the local repository path will be %USER_HOME%/.m2/repository.

Maven Custom Plug-In (Example Code)

Tagged : / / / / /

Issue Management In Maven?

rajeshatbuzz created the topic: issueManagement in Maven?
Any body provide some notes on issueManagement in Maven/.

Rajesh

scmuser replied the topic: Re:issueManagement in Maven?
issueManagement

Information about the issue tracking (or bug tracking) system used to manage this project.

Element

Description

system

The name of the issue management system, e.g. Bugzilla

url

URL for the issue management system used by the project.

Example:


Trac
trac.videolan.org/vlma

Tagged :

How Maven development started?

scmuser created the topic: How Maven development started?
How Maven development started?

rajeshatbuzz replied the topic: Re:How Maven development started?
Maven, a Yiddish word meaning accumulator of knowledge, was originally started as an attempt to
simplify the build processes in the Jakarta Turbine project. There were several projects each with their
own Ant build files that were all slightly different and JARs were checked into CVS. We wanted a
standard way to build the projects, a clear definition of what the project consisted of, an easy way to
publish project information and a way to share JARs across several projects.

Tagged :

Maven’s Objectives

scmuser created the topic: Maven’s Objectives
What is the maven main objectives?

rajeshatbuzz replied the topic: Re:Maven’s Objectives
Maven’s primary goal is to allow a developer to comprehend the complete state of a development effort in the shortest period of time. In order to attain this goal there are several areas of concern that Maven attempts to deal with:
• Making the build process easy
• Providing a uniform build system
• Providing quality project information
• Providing guidelines for best practices development
• Allowing transparent migration to new features

Making the build process easy
While using Maven doesn’t eliminate the need to know about the underlying mechanisms, Maven does provide a lot of shielding from the details.

Providing a uniform build system
Maven allows a project to build using its project object model (POM) and a set of plugins that are shared by all projects using Maven, providing a uniform build system. Once you familiarize yourself with how one Maven project builds you automatically know how all Maven projects build saving you immense amounts of time when trying to navigate many projects.

Providing quality project information
Maven provides plenty of useful project information that is in part taken from your POM and in part generated from your project’s sources. For example, Maven can provide:
• Change log document created directly from source control
• Cross referenced sources
• Mailing lists
• Dependency list
• Unit test reports including coverage
As Maven improves the information set provided will improve, all of which will be transparent to
users of Maven.
Other products can also provide Maven plugins to allow their set of project information alongside
some of the standard information given by Maven, all still based on the POM.

Providing guidelines for best practices development
Maven aims to gather current principles for best practices development, and make it easy to guide a
project in that direction.
For example, specification, execution, and reporting of unit tests are part of the normal build cycle
using Maven. Current unit testing best practices were used as guidelines:
• Keeping your test source code in a separate, but parallel source tree
• Using test case naming conventions to locate and execute tests
• Have test cases setup their environment and don’t rely on customizing the build for test
preparation.

Maven also aims to assist in project workflow such as release management and issue tracking.
Maven also suggests some guidelines on how to layout your project’s directory structure so that once
you learn the layout you can easily navigate any other project that uses Maven and the same defaults.

Allowing transparent migration to new features
Maven provides an easy way for Maven clients to update their installations so that they can take
advantage of any changes that been made to Maven itself.
Installation of new or updated plugins from third parties or Maven itself has been made trivial for this
reason.

Tagged :

Maven Troubleshooting

rajeshkumar created the topic: Maven troubleshooting
i would like to knpw “Most Common Issues in Maven”?

Any body can focus on this?
Regards,
Rajesh Kumar
Twitt me @ twitter.com/RajeshKumarIn

mnanjala replied the topic: Re:Maven troubleshooting
You may get error with Java Heap Size error.
Solution: set the Environment Variable of MAVEN_OPTS to “-Xms512m -Xmx512m -XX:MaxPermSize=1024m”

mnanjala replied the topic: Re:Maven troubleshooting
2)ArtifactResolutionException

This error generally occurs when Maven could not download dependencies. Possible causes for this error are:

1. The repository you have configured requires authentication and Maven failed to provide the correct credentials to the server. In this case, make sure your ${user.home}/.m2/settings.xml contains a declaration whose matches the of the plugin repository to use. See the Maven Settings Reference for more details.
2. The remote repository in question uses SSL and the JVM running Maven does not trust the certificate of the server.
5. Maven failed to save the files to your local repository.
4. You have configured Maven to perform strict checksum validation and the files to download got corrupted.
3. There is a general network problem that prevents Maven from accessing any remote repository, e.g. a missing proxy configuration.(Communication Issue local box and repo)

mnanjala replied the topic: Re:Maven troubleshooting
3)DuplicateProjectException
This error signals a collision of project identifiers during a reactor build. The coordinates for a project as given by its group id, artifact id and version must be unique within a reactor build. The usual cause for this error is a in one of the POMs so please verify the project coordinates are correctly set and valid.

mnanjala replied the topic: Re:Maven troubleshooting
InternalErrorException

This error indicates a bug in Maven itself.

1. Capture the debug output of the failing build, e.g. by adding the flag -X to the command line and redirecting the console output of Maven to a file:

mvn -X > debug.log

2.If interested report this bug to maven gurus you could submit a ticket in jira.codehaus.org/browse/MNG so we can avoid this bug in future provided bug has been fixed.It is said it is intermittent.

mnanjala replied the topic: Re:Maven troubleshooting
4) InvalidPluginDescriptorException
This error signals incomplete or wrong information in the descriptor for a plugin. The plugin descriptor is a special file in the plugin’s JAR file. An invalid descriptor is usually the result of bad driving while assembling the plugin. Please report this issue to the maintainer of the plugin in question.

Not a bad idea to try out another version of the plugin, there’s not much you as a user can do.

Tagged :

Apache Maven Gets Ready for Enterprise, Eclipse

rajeshkumar created the topic: Apache Maven Gets Ready for Enterprise, Eclipse
It’s exciting times for fans of Apache Maven. Developers who delve into both Java and Eclipse are the target for a new push by Apache Maven and its commercial backer, Sonatype, that aim to produce new tools designed to simplify use and encourage adoption.

The effort will result in the launch of Maven Studio for Eclipse, building on the open source M2Eclipse project. That’s going to be followed by the launch of the Maven Enterprise Suite, which will include an array of tools designed to serve as a one-stop shop for enterprise developers. Developer.com takes a look at the implications.

The Apache Maven project is used by over 3 million Java developers as a project and build management solution. Java developers also widely use the Eclipse IDE. At the intersection of Eclipse and Maven is the new Maven Studio for Eclipse announced this week by Maven commercial backer Sonatype.

“The primary focus of the first version of Maven Studio for Eclipse is what we call developer on-boarding,” Jason Van Zyl, CTO of Sonatype and creator of Maven told InternetNews.com. “What we found is that in a lot of organizations the biggest problem they have is trying to get new developers initialized and working with a new project — what we’ve tried to do is turn it into a one-click operation.”
Regards,
Rajesh Kumar
Twitt me @ twitter.com/RajeshKumarIn

Tagged :

Sonatype Introduces Maven Studio for Eclipse(TM)

rajeshkumar created the topic: Sonatype Introduces Maven Studio for Eclipse(TM)
Innovative Development Environment Enables the 3+ Million Maven Java(TM) Developers to Dramatically Improve Productivity

EclipseCon – March 22, 2010 – Sonatype, caretaker of the Maven project and leading provider of enterprise software development infrastructure, today announced Sonatype Maven Studio for Eclipse. The Studio is the only Eclipse Integrated Development Environment specifically optimized for Maven, the de facto standard for Java project and build management used by more than 3 million Java developers worldwide. The Studio accelerates developer productivity through a range of innovations including one-click onboarding — making developers fully productive in minutes rather than hours or even days.

“The process of onboarding new software developers is slow, cumbersome and prone to error,” said Mark Driver, vice president and research director in Gartner Research (NYSE: IT). “Lost productivity due to inadequate and ineffective onboarding processes is a ‘hidden tax’ that causes organizations to waste a great deal of time and money.”

Getting a new developer up and running can take up to a week of trial and error as they assemble a working development environment, struggling with project dependencies, plug-ins, preferences, and more. With one click, Maven Studio automatically installs and configures everything a developer needs to start delivering value to their organization.

With open source M2Eclipse at its core, Maven Studio for Eclipse will also deliver a number of innovations beyond one-click onboarding. These include:

* License management to ensure that all license headers and attribution files are present in the project, making the terms of the license legally enforceable
* Tomcat integration for rapid development of web applications
* Confluence Wiki integration, allowing developers to view and edit wiki content from inside Eclipse
* The ability to launch Hudson builds and monitor Hudson build status within the Eclipse IDE

Maven Studio for Eclipse also provides tight Maven platform integration, including support for Eclipse provisioning and workspace materialization, allowing developers to automatically install the Eclipse IDE, check out the project source and configure preferences. Maven Studio for Eclipse works closely with Nexus Professional and leverages its Eclipse repository support to make one-click onboarding seamless.

“Maven Studio for Eclipse enables a major advance in Java developer productivity, eliminating the wasted time of the typical trial and error process of assembling a working development environment,” said Jason van Zyl, CTO of Sonatype and creator of Maven. “Every organization using Maven and Eclipse will find the Studio indispensable to making a new team member fully productive.”
Regards,
Rajesh Kumar
Twitt me @ twitter.com/RajeshKumarIn

Tagged :

Maven failed to resolve repo1.maven.org Inbo

scmuser created the topic: Maven failed to resolve repo1.maven.org Inbo
I installed Maven 2.2.1 on Ubuntu 8.04. When I first tried to run mvn it
didn’t work.
I have a direct connection to internet and I do not have firewall policies
which prohibit
internet access from any program (such as java.exe, as I found in one post)

Looking at the stack-trace it seems like the root of all evil is:

Caused by: java.net.UnknownHostException: repo1.maven.org

I tried to resolve it manually

akshay@lap7:~$ dig repo1.maven.org.

; <<>> DiG 9.4.2-P2.1 <<>> repo1.maven.org.
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2732 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;repo1.maven.org. IN A ;; ANSWER SECTION: repo1.maven.org. 66 IN A 38.97.124.18 ;; Query time: 36 msec ;; SERVER: 192.168.1.1#53(192.168.1.1) ;; WHEN: Fri Jun 18 19:01:52 2010 ;; MSG SIZE rcvd: 49 Please suggest what is wrong with my setup. I've attached the output of mvn here. Thanks in advance. + Error stacktraces are turned on. Apache Maven 2.2.1 (r801777; 2009-08-07 00:46:01+0530) Java version: 1.6.0_03 Java home: /opt/jdk1.6.0_03/jre Default locale: en_IN, platform encoding: UTF-8 OS name: "linux" version: "2.6.24-27-generic" arch: "i386" Family: "unix" [DEBUG] Building Maven user-level plugin registry from: '/home/akshay/.m2/plugin-registry.xml' [DEBUG] Building Maven global-level plugin registry from: '/home/akshay/opt/apache-maven-2.2.1/conf/plugin-registry.xml' [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'archetype'. [DEBUG] Loading plugin prefixes from group: org.apache.maven.plugins [INFO] org.apache.maven.plugins: checking for updates from central [DEBUG] Using Wagon implementation lightweight from default mapping for protocol http [DEBUG] Checking for pre-existing User-Agent configuration. [DEBUG] Adding User-Agent configuration. [DEBUG] Connecting to repository: 'central' with url: ' repo1.maven.org/maven2 '. [DEBUG] Using Wagon implementation lightweight from default mapping for protocol http [WARNING] repository metadata for: 'org.apache.maven.plugins' could not be retrieved from repository: central due to an error: Error transferring file: repo1.maven.org [DEBUG] Exception org.apache.maven.wagon.TransferFailedException: Error transferring file: repo1.maven.org at org.apache.maven.wagon.providers.http.LightweightHttpWagon.fillInputData(LightweightHttpWagon.java:143) at org.apache.maven.wagon.StreamWagon.getInputStream(StreamWagon.java:116) at org.apache.maven.wagon.StreamWagon.getIfNewer(StreamWagon.java:88) at org.apache.maven.wagon.StreamWagon.get(StreamWagon.java:61) at org.apache.maven.artifact.manager.DefaultWagonManager.getRemoteFile(DefaultWagonManager.java:546) at org.apache.maven.artifact.manager.DefaultWagonManager.getArtifactMetadata(DefaultWagonManager.java:443) at org.apache.maven.artifact.repository.metadata.DefaultRepositoryMetadataManager.resolve(DefaultRepositoryMetadataManager.java:97) at org.apache.maven.plugin.DefaultPluginMappingManager.loadPluginMappings(DefaultPluginMappingManager.java:103) at org.apache.maven.plugin.DefaultPluginMappingManager.loadPluginMappings(DefaultPluginMappingManager.java:87) at org.apache.maven.plugin.DefaultPluginMappingManager.getByPrefix(DefaultPluginMappingManager.java:61) at org.apache.maven.plugin.DefaultPluginManager.getPluginDefinitionForPrefix(DefaultPluginManager.java:159) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.getMojoDescriptor(DefaultLifecycleExecutor.java:1801) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.segmentTaskListByAggregationNeeds(DefaultLifecycleExecutor.java:462) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:175) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138) at org.apache.maven.cli.MavenCli.main(MavenCli.java:362) at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: java.net.UnknownHostException: repo1.maven.org at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:177) at java.net.Socket.connect(Socket.java:519) at java.net.Socket.connect(Socket.java:469) at sun.net.NetworkClient.doConnect(NetworkClient.java:157) at sun.net.www.http.HttpClient.openServer(HttpClient.java:394) at sun.net.www.http.HttpClient.openServer(HttpClient.java:529) at sun.net. www.http.HttpClient .(HttpClient.java:233)
at sun.net.www.http.HttpClient.New(HttpClient.java:306)
at sun.net.www.http.HttpClient.New(HttpClient.java:323)
at
sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:788)
at
sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:729)
at
sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:654)
at
sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:977)
at
java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:373)
at
org.apache.maven.wagon.providers.http.LightweightHttpWagon.fillInputData(LightweightHttpWagon.java:115)
… 25 more
[INFO] Repository ‘central’ will be blacklisted
[DEBUG] Loading plugin prefixes from group: org.codehaus.mojo
[DEBUG] Skipping blacklisted repository central
[DEBUG] Skipping blacklisted repository central
[DEBUG] maven-archetype-plugin: using locally installed snapshot
[DEBUG] Artifact not found – using stub model: Unable to determine the
latest version

org.apache.maven.plugins:maven-archetype-plugin:pom:LATEST

[DEBUG] Using defaults for missing POM
org.apache.maven.plugins:maven-archetype-plugin:pom:LATEST
[DEBUG] maven-archetype-plugin: using locally installed snapshot
[DEBUG] Artifact not found – using stub model: Unable to determine the
release version

org.apache.maven.plugins:maven-archetype-plugin:pom:RELEASE

[DEBUG] Using defaults for missing POM
org.apache.maven.plugins:maven-archetype-plugin:pom:RELEASE
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] The plugin ‘org.apache.maven.plugins:maven-archetype-plugin’ does not
exist or no valid version could be found
[INFO]
[DEBUG] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: The plugin
‘org.apache.maven.plugins:maven-archetype-plugin’ does not exist or no valid
version could be found
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.verifyPlugin(DefaultLifecycleExecutor.java:1569)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.getMojoDescriptor(DefaultLifecycleExecutor.java:1851)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.segmentTaskListByAggregationNeeds(DefaultLifecycleExecutor.java:462)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:175)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
at
org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.maven.plugin.version.PluginVersionNotFoundException:
The plugin ‘org.apache.maven.plugins:maven-archetype-plugin’ does not exist
or no valid version could be found
at
org.apache.maven.plugin.version.DefaultPluginVersionManager.resolvePluginVersion(DefaultPluginVersionManager.java:229)
at
org.apache.maven.plugin.version.DefaultPluginVersionManager.resolvePluginVersion(DefaultPluginVersionManager.java:91)
at
org.apache.maven.plugin.DefaultPluginManager.verifyPlugin(DefaultPluginManager.java:179)
at
org.apache.maven.plugin.DefaultPluginManager.loadPluginDescriptor(DefaultPluginManager.java:1642)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.verifyPlugin(DefaultLifecycleExecutor.java:1540)
… 15 more
[INFO]
[INFO] Total time: 1 second
[INFO] Finished at: Fri Jun 18 15:43:35 GMT+05:30 2010
[INFO] Final Memory: 1M/4M
[INFO]

Tagged :

Run external tasks using maven

scmuser created the topic: Run external tasks using maven
Hi,
Is it possible to run ant tasks which is not connected with any build
lifecycle phase?
In other word I would like to perform some action on demand using maven and
antrun plugin

tpatil replied the topic: Re:Run external tasks using maven
Targets from external ant file can be run using maven-antrun-plugin.

maven-antrun-plugin

test






run


Also, you can execute the external command using maven-exec-plugin.

org.codehaus.mojo
exec-maven-plugin
1.1

compile
exec




svn

info
--xml

target/classes/svninfo.txt

Tagged :