Now that we have our project created, we can add in our code and utilize a whole new bag of Maven tricks. Note that the following commands must run in the same directory as the pom.xml file.
mvn test: Runs the JUnit tests for the application.
mvn package: Creates a .jar file from our project.
mvn install: Adds our project .jar to the repository for use as a dependency if needed.
mvn site: Generates the project website.
mvn clean: Cleans the output created in the target directory.
mvn eclipse:eclipse: Generates the Eclipse project file.
Let's look at something a little more complex. Starting a Java web project by hand can be even more time-consuming than starting a simple Java project by hand, but Maven makes it just as easy. The example below (ordinarily a single line, but wrapped to suit the web page format) sets up the project structure.
mvn archetype:create -DgroupId=com.oreilly -DartifactId=Oreilly -DarchetypeArtifactId=maven-archetype-webapp
The resulting structure looks like this:
Oreilly ----src ----main ----resources ----webapp ----WEB-INF
This time, our project was set up a little differently to support web resources that we will include in the .war file. The pom.xml file will contain a line that indicates that the project should be packaged into a .war file:
<packaging>war</packaging>. Now we are ready to create the .war file with
mvn package. Don't worry about how you'll get your dependencies into the WEB-INF/lib directory; Maven will include them automatically if the dependency's scope is set to
compile. We can also change the name of the .war file by simply adding the following to our pom.xml:
<build> <finalName>PromoteC</finalName> </build>
Now that we have created our project structure, written some code, and tested and compiled our application, we can move on look at how Maven handles dependencies. In order to add a dependency to your project, you need to add it to your pom.xml; the next time you run Maven, it will get that dependency from the Ibiblio repository and add it to your build path.
There are some very important things to remember about dependencies. The biggest inconvenience currently with Maven is that Sun .jars are not available through a Maven repository at the time of this writing. This is due to the licensing restrictions that Sun places on its code. To work around this issue, you have to download and install the code into your local repository or make a external declaration for a dependency location at a point on your file system. Hopefully, Sun will create their own Maven repository soon, but Maven will have to be updated to prompt the user to accept the licensing agreement before Maven can download the resource.
Another inconvenience is that sometimes you might be using a library that is very recent and might not exist in a remote repository. Another possibility is that you just might be developing with no internet access and just want to have all of your dependencies available locally. The best solution for these issues is to install the .jar in your local repository. It is also convenient to store your local repository on a web server, so that your entire development team can benefit and everyone doesn't have to manage his or her own repository. Changing the Maven repository path is as simple as editing the settings.xml file in the conf directory of the Maven distribution.
Using dependencies in Maven is simple. Let's look at adding a dependency to our pom.xml file above. We already have JUnit, but let's add the powerful Quartz library to our project. Quartz is an open source scheduling mechanism written entirely in Java and is a great choice for all of your scheduling needs.
<dependency> <groupId>quartz</groupId> <artifactId>quartz</artifactId> <version>1.5.1</version> <scope>compile</scope> </dependency>
That is all we need to add to the
<dependencies> element in order to get Maven to download and use Quartz as a dependency for our project. Don't worry about Quartz having dependencies. A Maven repository will contain information about dependencies for dependencies and when Maven downloads Quartz, all of its dependencies will also be downloaded. In order to verify that the 1.5.1 version of Quartz exists in Ibiblio, we can browse the Maven repository. Note the use of the
scope parameter; this tells Maven at which stage the dependency is needed. In the case of JUnit, we used the scope
test to tell Maven that this dependency is only needed in the testing phase and not as a runtime resource. Here is a guide to the available scopes.
compile: This is the default. States that the resource must be present for all tasks.
test: Runs all test cases.
runtime: This indicates that the resource is only needed as a runtime resource.
provided: This is for items that you expect to already be provided as part of the JDK or application server classpath.