Maven: The Complete Reference - 4.3. Common Lifecycle Goals |
|
Many of the packaging lifecycles have similar goals. If you look at
the goals bound to the WAR and JAR lifecycles, you’ll see that they
differ only in the The To illustrate resource filtering, assume that you have a project with an XML file in src/main/resources/META-INF/service.xml. You want to externalize some configuration variables to a properties file. In other words, you might want to reference a JDBC URL, username, and password for your database, and you don’t want to put these values directly into the service.xml file. Instead, you would like to use a properties file to capture all of the configuration points for your program. Doing this will allow you to consolidate all configuration into a single properties file and make it easier to change configuration values when you need to target a new deployment environment. First, take a look at the contents of service.xml in src/main/resources/META-INF. Using Properties in Project Resources. <service> <!-- This URL was set by project version ${project.version} --> <url>${jdbc.url}</url> <user>${jdbc.username}</user> <password>${jdbc.password}</password> </service>
This XML file uses the same property reference syntax you can use in
the POM. In fact, the first variable referenced is the default.properties in src/main/filters. jdbc.url=jdbc:hsqldb:mem:mydb jdbc.username=sa jdbc.password=
To configure resource filtering with this default.properties file,
we need to specify two things in a project’s POM: a list of properties
files in the Filter Resources (Replacing Properties). <build> <filters> <filter>src/main/filters/default.properties</filter> </filters> <resources> <resource> <directory>src/main/resources</directory> <filtering>true</filtering> </resource> </resources> </build>
As with all directories in Maven, the resources directory does not
need to be in src/main/resources. This is just the default value
defined in the Super POM. You should also note that you don’t need to
consolidate all of your resources into a single directory. You can
always separate resources into separate directories under
src/main. Assume that you have a project which contains hundreds of
XML documents and hundreds of images. Instead of mixing the resources
in the src/main/resources directory, you might want to create two
directories src/main/xml and src/main/images to hold this
content. To add directories to the list of resource directories, you
would add the following Configuring Additional Resource Directories. <build> ... <resources> <resource> <directory>src/main/resources</directory> </resource> <resource> <directory>src/main/xml</directory> </resource> <resource> <directory>src/main/images</directory> </resource> </resources> ... </build>
When you are building a project that produces a console application or a command-line tool, you’ll often find yourself writing simple shell scripts that need to reference the JAR produced by a build. When you are using the assembly plugin to produce a distribution for an application as a ZIP or TAR, you might place all of your scripts in a directory like src/main/command. In the following POM resource configuration, you’ll see how we can use resource filtering and a reference to the project variable to capture the final output name of the JAR. For more information about the Maven Assembly plugin, see Chapter 8, Maven Assemblies. <build> <groupId>org.sonatype.mavenbook</groupId> <artifactId>simple-cmd</artifactId> <version>2.3.1</version> ... <resources> <resource> <filtering>true</filtering> <directory>${basedir}/src/main/command</directory> <includes> <include>run.bat</include> <include>run.sh</include> </includes> <targetPath>${basedir}</targetPath> </resource> <resource> <directory>${basedir}/src/main/resources</directory> </resource> </resources> ... </build>
If you run mvn process-resources in this project, you will end up
with two files, run.sh and run.bat, in ${basedir}. We’ve
singled out these two files in a @echo off java -jar ${project.build.finalName}.jar %* After running @echo off java -jar simple-cmd-2.3.1.jar %* The ability to customize filtering for specific subsets of resources is another reason why complex projects with many different kinds of resources often find it advantageous to separate resources into multiple directories. The alternative to storing different kinds of resources with different filtering requirements in different directories is to use a more complex set of include and exclude patterns to match all resource files which match a certain pattern. Most lifecycles bind the Compiler plugin’s Setting the Source and Target Versions for the Compiler Plugin. <project> ... <build> ... <plugins> <plugin> <artifactId>maven-compiler-plugin</artifactId> <configuration> <source>1.5</source> <target>1.5</target> </configuration> </plugin> </plugins> ... </build> ... </project>
Notice we are configuring the Compiler plugin, and not the specific
If you need to customize the location of the source code, you can do
so by changing the build configuration. If you wanted to store your
project’s source code in src/java instead of src/main/java and if
you wanted build output to go to classes instead of
target/classes, you could always override the default
Overriding the Default Source Directory. <build> ... <sourceDirectory>src/java</sourceDirectory> <outputDirectory>classes</outputDirectory> ... </build>
WarningWhile it might seem necessary to bend Maven to your own idea of project directory structure, we can’t emphasize enough that you should sacrifice your own ideas of directory structure in favor of the Maven defaults. This isn’t because we’re trying to brainwash you into accepting the Maven Way, but it will be easier for people to understand your project if it adheres to the most basic conventions. Just forget about this. Don’t do it. The The As with the source code directory, if you want to customize the
location of the test source code and the output of test compilation,
you can do so by overriding the Overriding the Location of Test Source and Output. <build> ... <testSourceDirectory>src-test</testSourceDirectory> <testOutputDirectory>classes-test</testOutputDirectory> ... </build>
Most lifecycles bind the test goal of the Surefire plugin to the test phase. The Surefire plugin is Maven’s unit testing plugin, the default behavior of Surefire is to look for all classes ending in *Test in the test source directory and to run them as JUnit tests. The Surefire plugin can also be configured to run TestNG unit tests. After running If you are working on a project that has some failing unit tests, but
you want the project to produce output, you’ll need to configure the
Surefire plugin to continue a build even if it encounters a
failure. The default behavior is to stop a build whenever a unit test
failure is encountered. To override this behavior, you’ll need to set
the Configuring Surefire to Ignore Test Failures. <build> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-surefire-plugin</artifactId> <configuration> <testFailureIgnore>true</testFailureIgnore> </configuration> </plugin> ... </plugins> </build>
If you would like to skip tests altogether, you can do so by executing the following command: $ mvn install -Dmaven.test.skip=true The The The |