Creating empty directories using jdeb plugin maven

<!-- Package data (templates [empty directories]) -->
        <data>
         <type>template</type>
         <paths>
          <path>/var/lib/direct/direct-cert-discovery-tool</path>
          <path>/var/lib/direct/mail/badmsg</path>
          <path>/var/lib/direct/mail/inmsg</path>
          <path>/var/lib/direct/mail/outmsg</path>
          <path>/var/lib/direct/mail/rawmsg</path>
         </paths>
        </data>

Maven assembly plugin

The Maven Assembly plugin is a plugin you can use to create arbitrary distributions for your applications. You can use the Maven Assembly plugin to assemble the output of your project in any format you desire by defining a custom assembly descriptor.
we’re going to use the predefined jar-with-dependencies format. To configure the Maven Assembly Plugin, we need to add the following plugin configuration to our existing build configuration in the pom.xml.

<build>
        <plugins>
            <plugin>
                <artifactId>maven-assembly-plugin</artifactId>
                <configuration>
                    <descriptorRefs>
                        <descriptorRef>jar-with-dependencies</descriptorRef>
                    </descriptorRefs>
                </configuration>
            </plugin>
        </plugins>
    </build>

Once you’ve added this configuration, you can build the assembly by running the assembly:assembly goal. In the following screen listing, the assembly:assembly goal is executed after the Maven build reaches the install lifecycle phase:
 While it is certainly valid to execute a plugin goal directly from the command-line as we just demonstrated, it is more consistent with the design of Maven to configure the Assembly plugin to execute the assembly:assembly goal during a phase in the Maven lifecycle.

The following plugin configuration configures the Maven Assembly plugin to execute the attached goal during the package phase of the Maven default build lifecycle. The attached goal does the same thing as the assembly goal. To bind to assembly:attached goal to thepackage phase we use the executions element under plugin in the build section of the project’s POM.

<plugin>
                <artifactId>maven-assembly-plugin</artifactId>
                <configuration>
                    <descriptorRefs>
                        <descriptorRef>jar-with-dependencies</descriptorRef>
                    </descriptorRefs>
                </configuration>
                <executions>
                    <execution>
                        <id>simple-command</id>
                        <phase>package</phase>
                        <goals>
                            <goal>attached</goal>
                        </goals>
                    </execution>
                </executions>
            </plugin>

Once you have this configuration in your POM, all you need to do to generate the assembly is run mvn package. The execution configuration will make sure that the assembly:attached goal is executed when the Maven lifecycle transitions to the package phase of the lifecycle. The assembly will also be created if you run mvn install as the package phase precedes the install phase in the default Maven lifecycle.

Running without using jars in the classpath

The Exec plugin makes it possible for us to run the simplest weather program without having to load the appropriate dependencies into the classpath. In any other build system, we would have to copy all of the program dependencies into some sort of lib/ directory containing a collection of JAR files. Then, we would have to write a simple script that includes our program’s bytecode and all of our dependencies in a classpath. Only then could we run java org.sonatype.mavenbook.weather.Main. The Exec plugin leverages the fact that Maven already knows how to create and manage your classpath and dependencies.

mvn exec:java -Dexec.mainClass=org.sonatype.mavenbook.weather.Main \
      -Dexec.args="70112"

This is convenient, but it’s also nice to know exactly what is being included in your project’s classpath. Although the project depends on a few libraries such as Dom4J, Log4J, Jaxen, and Velocity, it also relies on a few transitive dependencies. If you need to find out what is on the classpath, you can use the Maven Dependency plugin to print out a

mvn dependency:resolve

  

mvn dependency:tree

Create multiple runnable jars from a single project

http://stackoverflow.com/questions/8726884/create-multiple-runnable-jars-with-depencies-included-from-a-single-maven-proj

Annotations are not supported in source 1.3 maven

Maven compiler plugin uses default JDK1.3 which does not support annotations.

Solution :

<project ....>
 <build>
  <plugins>
 <plugin>
  <artifactId>maven-compiler-plugin</artifactId>
  <version>2.3.2</version>
  <configuration>
   <source>1.6</source>
   <target>1.6</target>
  </configuration>
 </plugin>
   </plugins>
  </build>
</project>

What is lifecycle phase ?

Lifecycle phases are intentionally vague, defined solely as validation, testing, or deployment, and they may mean different things to different projects. For example, in a project that produces a Java archive, the package phase produces a JAR; in a project that produces a web application, the package phase produces a WAR.
Plugin goals can be attached to a lifecycle phase. As Maven moves through the phases in a lifecycle, it will execute the goals attached to each particular phase. 

What are maven goals ?

Goals define parameters that can define sensible default values. 

In the archetype:generate exam- ple, we did not specify what kind of archetype the goal was to create on our command line; we simply passed in a groupId and an artifactId. Not passing in the type of artifact we wanted to create caused the generate goal to prompt us for input, the generate goal stopped and asked us to choose an archetype from a list. If you had run the archetype:create goal instead, Maven would have as- sumed that you wanted to generate a new project using the default maven-archetype-quickstart archetype. This is our first brush with convention over configuration. The convention, or default, for the create goal is to create a simple project called Quickstart. The create goal defines a configuration property archetypeArtifactId that has a default value of maven-archetype-quickstart. The Quickstart archetype generates a minimal project shell that contains a POM and a single class. 

The Archetype plugin is far more powerful than this first example suggests, but it is a great way to get new projects started fast. Later in this book, we’ll show you how the Archetype plugin can be used to generate more complex projects such as web applications, and how you can use the Archetype plugin to define your own set of projects. 

What is a maven plugin ?

To execute a single Maven plugin goal, we used the syntax mvn archetype:generate, where archetype is the identifier of a plugin and generate is the identifier of a goal.

A Maven Plugin is a collection of one or more goals. Examples of Maven plugins can be simple core plugins like the Jar plugin, which contains goals for creating JAR files, Compiler plugin, which contains goals for compiling source code and unit tests, or the Surefire plugin, which contains goals for executing unit tests and generating reports. Other, more specialized Maven plugins include plugins like the Hiber- nate3 plugin for integration with the popular persistence library Hibernate, the JRuby plugin which allows you to execute ruby as part of a Maven build or to write Maven plugins in Ruby. Maven also provides for the ability to define custom plugins. 

The core of Maven has little to do with the specific tasks involved in your project’s build. By itself, Maven doesn’t know how to compile your code or even how to make a JAR file. It delegates all of this work to Maven plugins like the Compiler plugin and the Jar plugin, which are downloaded on an as-needed basis and periodically updated from the central Maven repository. When you download Maven, you are getting the core of Maven, which consists of a very basic shell that knows only how to parse the command line, manage a classpath, parse a POM file, and download Maven plugins as needed. By keeping the Compiler plugin separate from Maven’s core and providing for an update mechanism, Maven makes it easier for users to have access to the latest options in the compiler. In this way, Maven plugins allow for universal reusability of common build logic. You are not defining the compile task in a build file; you are using a Compiler plugin that is shared by every user of Maven. If there is an improvement to the Compiler plugin, every project that uses Maven can immediately benefit from this change. (And, if you don’t like the Compiler plugin, you can override it with your own implementation.) 

What is archetype or How can you create a maven project ?

 mvn archetype:generate -DgroupId=org.sonatype.mavenbook \
-DartifactId=simple \
-Dpackage=org.sonatype.mavenbook \
-Dversion=1.0-SNAPSHOT

An archetype is defined as “an original model or type after which other similar things are patterned; a prototype.” A number of archetypes are available in Maven for anything from a simple application to a complex web application, and the archetype:generate offers a list of archetypes to choose from. The plugin is the prefix archetype, and the goal is generate.











The Maven Archetype plugin creates a directory simple/ that matches the artifactId. This is every Maven project has what is known as a Project Object Model (POM) in a file named pom.xml. This file describes the project, configures plugins, and declares dependencies. Our project’s source code and resources are placed under src/main. In the case of our simple Java project this will consist of a few Java classes and some properties file. In another project, this





could be the document root of a web application or configuration files for an application server.



src/main/java and classpath resources are placed in
In a Java project, Java classes are placed in
 

src/main/resources.





TestNG tests are placed in src/test/java, and classpath resources for tests are located in src/test/re-








Our project’s test cases are located in src/test. Under this directory, Java classes such as JUnit or

sources.

How to compare maven and ant ?

Apache Ant

• Ant doesn’t have formal conventions like a common project directory structure or default behav- ior. You have to tell Ant exactly where to find the source and where to put the output. Informal conventions have emerged over time, but they haven’t been codified into the product.
  
• Ant is procedural. You have to tell Ant exactly what to do and when to do it. You have to tell it to compile, then copy, then compress.
  
• Ant doesn’t have a lifecycle. You have to define goals and goal dependencies. You have to attach a sequence of tasks to each goal manually.
  
  

Apache Maven

• Mavenhasconventions.Itknowswhereyoursourcecodeisbecauseyoufollowedtheconvention. Maven’s Compiler plugin put the bytecode in target/classes, and it produces a JAR file in target.
  
• Maven is declarative. All you had to do was create a pom.xml file and put your source in the default directory. Maven took care of the rest.
  
• Maven has a lifecycle which was invoked when you executed mvn install. This command told Maven to execute a series of sequential lifecycle phases until it reached the install lifecycle phase. As a side-effect of this journey through the lifecycle, Maven executed a number of default plugin goals which did things like compile and create a JAR. 
  

0. Maven has built-in intelligence about common project tasks in the form of Maven plugins. If you wanted
   to write and execute unit tests, all you would need to do is write the tests, place them in ${basedir}/src/test/java, addatest-scopeddependencyoneitherTestNGorJUnit,andrunmvn test.Ifyouwantedtodeploya web application and not a JAR, all you would need to do is change your project type to war and put your docroot in ${basedir}/src/main/webapp. Sure, you can do all of this with Ant, but you will be writing
   the instructions from scratch. In Ant, you would first have to figure out where the JUnit JAR file should
   be. Then you would have to create a classpath that includes the JUnit JAR file. Then you would tell
   Ant where it should look for test source code, write a goal that compiles the test source to bytecode, and execute the unit tests with JUnit. 
   

Without supporting technologies like antlibs and Ivy (even with these supporting technologies), Ant has the feeling of a custom procedural build. An efficient set of Maven POMs in a project which adheres to Maven’s assumed conventions has surprisingly little XML compared to the Ant alternative. Another benefit of Maven is the reliance on widely-shared Maven plugins. Everyone uses the Maven Surefire plugin for unit testing, and if someone adds support for a new unit testing framework, you can gain new capabilities in your own build by just incrementing the version of a particular Maven plugin in your project’s POM.
The decision to use Maven or Ant isn’t a binary one, and Ant still has a place in a complex build. If your current build contains some highly customized process, or if you’ve written some Ant scripts to complete a specific process in a specific way that cannot be adapted to the Maven standards, you can still use these scripts with Maven. Ant is made available as a core Maven plugin. Custom Maven plugins can be implemented in Ant, and Maven projects can be configured to execute Ant scripts within the Maven project lifecycle. 

How do we add the jars to the class path ussing maven ?

http://maven.apache.org/plugins/maven-dependency-plugin/
http://stackoverflow.com/questions/4687609/maven-not-setting-classpath-for-dependencies-properly
http://maven.apache.org/plugins/maven-dependency-plugin/

<build>

        <plugins>

        <plugin>

            <groupId>org.apache.maven.plugins</groupId>

            <artifactId>maven-dependency-plugin</artifactId>

            <executions>

                <execution>

                    <id>copy-dependencies</id>

                    <phase>prepare-package</phase>

                    <goals>

                        <goal>copy-dependencies</goal>

                    </goals>

                    <configuration>

                        <outputDirectory>/User/sayghosh/code/CCMatching/lib/</outputDirectory>

                        <overWriteReleases>false</overWriteReleases>

                        <overWriteSnapshots>false</overWriteSnapshots>

                        <overWriteIfNewer>true</overWriteIfNewer>

                    </configuration>

                </execution>

            </executions>

        </plugin>

        <plugin>

            <groupId>org.apache.maven.plugins</groupId>

            <artifactId>maven-jar-plugin</artifactId>

            <configuration>

                <archive>

                    <manifest>

                        <addClasspath>true</addClasspath>

                        <classpathPrefix></classpathPrefix>

                        <mainClass><com.sd.sd.sd></mainClass>

                    </manifest>

                </archive>

            </configuration>

        </plugin>

        </plugins>

        </build>

What is M2_REPO and what does mvn:eclipse eclipse do ?

First step is to be able to create a pom.xml, then you have to be able to get mvn:compile and mvn:package running. After that comes your eclipse repo the dev environment, in this page you get that running. Next how do you add jars to the classpath to get the jar running. 

1. M2_REPO is a variable that defines where maven 2 repository is on your disk
2. This means: add definition of M2_REPO to XML file that defines the eclipse workspace
3. You can do the same manually if you want. That is what I personally did. Just go to Window/Preferences and then choose Java/Build Path/Classpath Variables. Once you did it you can enjoy maven integration with eclipse. Every time you add new dependency to your pom.xml, run
   mvn eclipse:eclipse

and refresh you workspace you get all new libraries into classpath of your project.

If you have a simple java project which is made up of only one module, using eclipse is very simple. To generate the eclipse project files from your POM you execute the following command:

mvn eclipse:eclipse

If you have created or checked out the project with eclipse, you only have to refresh the project in your workspace. Otherwise you have to import the project into your eclipse workspace (From the menu bar, select File >Import >Existing Projects into Workspace). In the latter case the project (directory) should not be located in your workspace, because eclipse might come into trouble, especially if you want to use eclipse as the scm client.

http://stackoverflow.com/questions/4517507/setting-up-m2-repo-classpath
http://maven.apache.org/guides/mini/guide-ide-eclipse.html