maven

I came across a situation today where Maven threw an OutOfMemoryException. I didn’t think the process would have taken that much memory but it clearly did. I was trying to deploy. I then tried it again but skipped the tests. No good. I found out that by setting the MAVEN_OPTS environment variable to something like -Xmx512m I was good to go.

I’ve collected a short list of commands I use for maven and thought I’d share.

Install to Local Repository Compile Test Classes, Do Not Run Tests

mvn -Dmaven.test.skip.exec install

Install to Local Repository Do Not Compile Test Classes, Do Not Run Tests

 mvn -Dmaven.test.skip install

Generate Test Results in HTML Format (tests will be run)

mvn surefire-report:report

Generate Test Results in HTML Format (tests will not be run, source of reports will be last tests run)

mvn surefire-report:report-only

Run Specific Test Class

mvn -Dtest=MyTestClass test

Use Patterns to Run Specific Tests

mvn -Dtest=MyTest*lass test

Run Multiple Specific Test Classes

 mvn -Dtest=UnitTestClass,Accep*TestClass test

View Dependency Tree: output is a mono-spaced tree views of all classes in the current artifact

mvn dependency:tree

Download Sources: Usually when using Maven only the binary version of your dependency are fetched from the repository. This will tell Maven to download the sources of your dependencies.

mvn [goal] -DdownloadSources=true

Download Java Docs: Same as with sources, Maven doesn’t usually grab the JavaDocs.

mvn [goal] -DdownloadJavadocs=true

Show the Effective POM: This is the final pom that is used to perform the goal.

mvn help:effective-pom

At work (http://www.monsanto.com/) we’re converting all projects from Apache ant to Apache maven. The architecture team came up with the POM which all our applications would extend and set up the company-wide repository. I spent about a week and a half converting our project. Everyone thought that conversions would go smoothly. However, I haven’t heard of any project taking less than a week. A colleague wrote an application called “mavenizer”. The mavenizer helps analyze your project and generates a POM for each artifact. We had to determine how to split our application into artifacts but using the mavenizer app helped us figure out the dependencies and got us started with an initial POM.

I can’t speak for other projects but probably the most time consuming part of the process was weeding out the dependencies. We had some production code that had interdependencies but the majority was located in the test code. For instance, we have a TestHelper class that provides methods setting up the data environment prior to running a test and for tearing it down once the test completes. This class was used in a couple of leaf artifacts (domainpos and batchprocess).

When working with maven each, for lack of a better word, installable module is packaged in what’s known as an artifact. An “installable” would be something like a jar or war or ear or some other unit. We have a “common” artifact that’s a jar and can be used by all other artifacts. Then there is an “appdao” jar which contains all database-related code. Finally there are 3 leaf artifacts which can depend on the common and/or appdao but should not depend on each other: domainpos (war that is our point-of-service); plugin (jar that is a plugin for the company-wide GUI framework); batchprocess (jar that runs on a schedule for batch processing).

I’ll post here more about the conversion process and about things I learn about maven.