Maven 2
From Guides
Contents |
Getting Started
If you have never done anything with Maven before I recommend you get started here to get you up and running asap.
Maven Getting Started
Maven 2 XSD
It is always convenient to have code completion on the pom.xml file in eclipse. That is why I always add the maven xsd. I will place the snippet below so you can copy paste it.
<?xml version="1.0" encoding="UTF-8"?> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd"> </project>
Projects
You can create projects by using archetypes (templates) which are defined in the maven repository. Here are the two most basic archetypes.
There are many more archetypes but I often find them bloated. I'd rather start with a small project file which grows slowly.
- Creating a default project
mvn archetype:create -DgroupId=com.mycompany.app -DartifactId=my-app
- Creating a web application
mvn archetype:create -DgroupId=com.mycompany.app -DartifactId=my-webapp -DarchetypeArtifactId=maven-archetype-webapp
Own Archetypes
I could sum this up here but instead I will provide you with this link which is a good starting point. Creating Archetypes
- Importing a archetype into your repository
mvn install:install-file -DgroupId=org.webapp -DartifactId=spring-hibernate -Dversion=1.0 -Dpackaging=jar -Dfile=spring-hibernate-1.0.jar
- Create a project with the archetype
mvn archetype:create -DarchetypeGroupId=org.webapp -DarchetypeArtifactId=spring-hibernate -DarchetypeVersion=1.0 -DgroupId=<your.groupid> -DartifactId=<your-artifactId>
Importing Jars into Repository
You might have dependencies which are not available in the maven repository. To be able to use them during the build process you can import them into your local repository by executing the following command (using cfusion jar as example here):
mvn install:install-file -DgroupId=local -DartifactId=cfusion -Dversion=7.0 -Dpackaging=jar -Dfile=C:\dev\classpath\cfusion.jar
This command will create a folder named "local". In there another folder is created that is named after the specified version (7.0). The jar will be placed inside this directory.
You can now use the jar in your project by placing a dependency in your pom.xml file.
<dependency>
<groupId>local</groupId>
<artifactId>cfusion</artifactId>
<version>7.0</version>
</dependency>
Default Directory Layout
This is the default directory layout for a Maven project:
src/main/java Application/Library sources src/main/resources Application/Library resources src/main/filters Resource filter files src/main/assembly Assembly descriptors src/main/config Configuration files src/main/webapp Web application sources src/test/java Test sources src/test/resources Test resources src/test/filters Test resource filter files src/site Site LICENSE.txt Project's license README.txt Project's readme
Creating IntelliJ or Eclipse project
If you have generated or checked out source you can create project files you can use with your favourite IDE. I will only list IntelliJ and Eclipse here there are probably more plugins available for use with other IDE's.
- IntelliJ
mvn idea:idea
- Eclipse
mvn eclipse:eclipse -DdownloadSources=true
-DdownloadSources will try to download the sources of each jar. (Easy for code completion/lookups) Well ain't that just easy? ;)
There are several plugins available for Eclipse. I use the Sonatype maven2 plugin which will be integrated in eclipse in future releases. Eclipse Plugin Site
Skipping tests
Testing is cool, but not all the time. Remember when you changed that one line of code to fix a really small bug and you had to grab a pot of coffee waiting for the tests to complete? As a seasoned maven user you probably already knew you could use this parameter in conjuction with maven to skip these tests:
mvn <target> -Dmaven.test.skip=true
You could also just edit your pom.xml and configure the surefire plugin to skip testing everytime (xml-path: project->build->plugins)
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<skip>true</skip>
</configuration>
</plugin>
Properties and Filters
Buildtime variable properties that need to be replaced by a specific value can be inserted into your code by using the following syntax:
${propertyname}
Most of these values you can set yourself. But some values are global. I tried to see if I could find any of these global defined values but I couldn't find them anywhere in the available documentation.
The global values I found so far:
${basedir} The directory your pom.xml resides in
${project.build.directory} The output directory
${pom.*.*} To refer to your current pom.xml values,
from here you can navigate the xml-tree to lookup a value.
You can define your own properties in your POM by using this tag within the project tag:
(xml-path: project)
<!-- Pom Defined Properties --> <properties> <!-- You can override this command from the console --> <!-- Use: mvn <target> -Dfilter.properties = <yourPropertyValue> --> <filter.properties>yourPropertyValue</filter.properties> </properties>
You can then filter ${filter.properties} to be replaced with the value of that property at build time.
To process the files you which to filter use the following:
(xml-path: project->build)
<!-- Load in Filter properties -->
<filters>
<filter>src/main/filters/${filter.properties}</filter>
</filters>
<!-- Execute filter with set properties -->
<resources>
<resource>
<filtering>true</filtering>
<directory>src/main/resources</directory>
</resource>
</resources>
To read more about filtering you can look here: Filtering
Profiles
By using profiles you can apply certain settings by activating a profile. This can happen automatically based on some environment settings or you can activate them by hand.
let's assume you have some specific settings which are different for a release build.
<profiles>
<!-- Default Profile -->
<profile>
<id>default</id>
<activation>
<activeByDefault>true</activeByDefault>
</activation>
<build>
<finalName>${project.artifactId}</finalName>
</build>
<properties>
<!-- Default DB Properties -->
<maven.dynamic.property>yourCustomValueHere</maven.dynamic.property.name>
</properties>
</profile>
</profiles>
This profile is active by default. But you could create an extra profile with a different id and activate it by using the -P switch on the maven command line. You can also combine profiles. Let's assume you have this profile:
<profiles> <!-- Default Profile --> <profile> <id>myProfile</id> <properties> <!-- Default DB Properties --> <maven.dynamic.property>myCustomValueHere</maven.dynamic.property.name> </properties> </profile> </profiles>
Now if you would run maven with '-P default myProfile' the maven.dynamic.property value from myProfile would overrule the one in the default profile but the other settings from the default profile would be applied too. Very handy when you have different builds.
Lifecycle / Phase
| Phase | Description |
|---|---|
| validate | Validate the project is correct and all necessary information is available. |
| generate-sources | Generate any source code for inclusion in compilation. |
| process-sources | Process the source code, for example to filter any values. |
| generate-resources | Generate resources for inclusion in the package. |
| process-resources | Copy and process the resources into the destination directory, ready for packaging. |
| compile | Compile the source code of the project. |
| process-classes | Post-process the generated files from compilation, for example to do bytecode enhancement on Java classes. |
| generate-test-sources | Generate any test source code for inclusion in compilation. |
| process-test-sources | Process the test source code, for example to filter any values. |
| generate-test-resources | Create resources for testing. |
| process-test-resources | Copy and process the resources into the test destination directory. |
| test-compile | Compile the test source code into the test destination directory |
| test | Run tests using a suitable unit testing framework. These tests should not require the code be packaged or deployed. |
| prepare-package | Perform any operations necessary to prepare a package before the actual packaging. This often results in an unpacked, processed version of the package. |
| package | Take the compiled code and package it in its distributable format, such as a JAR. |
| pre-integration-test | Perform actions required before integration tests are executed. This may involve things such as setting up the required environment. |
| integration-test | Process and deploy the package if necessary into an environment where integration tests can be run. |
| post-integration-test | Perform actions required after integration tests have been executed. This may include cleaning up the environment. |
| 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. |
To read more look here: lifecycle
Links
More interesting reading material can be found here:
