Maven Tips
Posted by Lars Vonk in the early afternoon: October 25th, 2008
I use Maven 2 a lot in projects for quite some years now. Here a some random tips from my previous experiences that I'd like to share.
1. Explicitly mention the version of all your plugins and reporting plugins.
If you don't mention your plugin version explicitly you are subject to unexpected behavior caused by unexpected updates or different versions used on different machines.
2. Put your internal repositories in your settings.xml.
This one I bumped into recently. We had setup an internal Maven repo, but were unable to assign a nice url so we had to use the ipaddress. A couple of months later we had to migrate the Maven repo to another location... This meant we had to change all poms that had a reference to that internal Maven repo. Since we are still not able to get a nice url we decided to put the internal Maven repo in the settings.xml and distribute that part of the settings.xml to all developers.
3. Use
For instance if you use Spring declare your spring dependencies as:
<properties> <spring.version>2.5.5</spring.version> </properties> ... <dependency> <artifactId>spring</artifactId> <version>${spring.version}</version> </dependency> <dependency> <artifactId>spring-test</artifactId> <version>${spring.version}</version> </dependency>
Advantage is that you can upgrade your version in one place, especially handy in multi projects.
4. Generate .project and .classpath using mvn eclipse:eclipse (or idea:idea etc).
This way you know your .classpath and .project are always in synch with your pom.xml.
5. Create a parent pom that contains info for generating sites and containing all distribution management stuff.
By abstracting these settings in a parent pom you don't have to repeat yourself and you are able to upgrade your site or change your distribution strategy in one place.
6. Configure site reports too provide value instead of using them out of the box.
If you use your Maven site reports out of the box they generate a lot of noise. If you really want to benefit from them tweak them to meet your team's need. I wrote a blogpost on this topic earlier.
7. Use the jetty-maven-plugin for web applications
I really like the jetty-maven-plugin when working on web applications. It is easy to configure and very stable, there are no strange things happening like crashing Eclipses I always experience with WTP (or is it just me?).
8. Use the maven-release-plugin for releasing
This plugin saves you a lot of manual work in upgrading pom versions, manually (via mvn deploy) deploying artifacts in the Maven repository.
9. Add your own Maven repository in your project
This one I got via the Wicket User Group. Sometimes you need a dependency that is not in any Maven repository and you also don't have (access) to a (company) Maven repository. In this case you can add a Maven repository in your project (for instance in ${basedir}/repository. Install the missing artifact in that folder and add your newly created repository in your pom.xml.
... <repository> <id>project-local-repo</id> <url>file:///./repository</url> </repository> ...
This is of course a nasty hack, but can be quite handy if you don't know how to move on.
That's it. Do you have other neat Maven tips?
Archives
Xebia Sites
Categories
- Java (279)
- Agile (109)
- General (50)
- Testing (42)
- Performance (42)
- Hibernate (36)
- Scrum (33)
- Podcast (31)
- Architecture (31)
- Spring (28)
- SOA (24)
- Maven (22)
- Project Management (22)
- Flex (17)
- JPA (17)
- Eclipse (15)
- Quality Assurance (14)
- Middleware (19)
- Frameworks (13)
Hi Lars,
Thanks for the tips. One small remark: I’m using IntelliJ, and I never use the maven plugin to generate my project: I just open the pom.xml from within my IDE, which works great.
I’m sure Eclipse (m2eclipe?) has similar tools. This way, you’re project is always in sync with your pom, and you don’t have to manually sync it when adding dependencies.
Oh, and about point 2: I would advice to put in in the pom
. Actually, I would put all maven repositories there, internal or external. It happend to often that a build was failing on my machine, only to be notified (too much time later…) by an other developer that a new repo was added, but since it was in his/her settings, and not in a global place, my build was failing….
A workaround for your problem could be to ’standardize’ on hostnames, and add them to your /etc/hosts file (or your windows host file). This way you can refer to them by name, and when the IP address changes, you only have to change your host table!
Good summary. Definately putting the repos in your settings is the way to go as you discovered. Having them in the pom makes it a tiny bit simpler to setup a new user, but it can be quite a pain to migrate later. Inserting the file based repo in your pom is also a bad idea, if you really must do it, put it in your settings.
A better idea is a repository manager like Nexus (http://nexus.sonatype.org) even for personal use. It makes it easier to manager your repository connections, upload 3rd party resources etc. Plus you can trash your local repo and not have to redownload everything from the net.
As for using the properties for versioning, maybe you can use instead.
This also regulates the versioning of transitive dependencies.
In my previous post the word dependencyManagement disappeared, as I put it in between
A section of the maven introduction handles this issue:
http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Management
(I also seem to have some issues with your software)
why dont you put the company repos in the parent pom ? migration is simple then, noone even notices.
We’ve got a whole collection of advice on how to get a proper Maven infrastructure up and running:
http://wiki.community.objectware.no/display/smidigtonull/Enterprise+Maven+Infrastructure
And here’s our pretty extensive Maven FAQ:
http://wiki.community.objectware.no/display/smidigtonull/Maven+FAQ