Lives in the UK. Likes blogging, cycling and eating lemon drizzle cake. Roger is a DZone MVB and is not an employee of DZone and has posted 143 posts at DZone. You can read more from them at their website. View Full User Profile

Using Maven's -U Command Line Option

03.11.2012
| 17320 views |
  • submit to reddit

In my experience when working on a multi-model project, the developers on that project tend to grab hold of all the project’s source code and build it all using some kind of Maven build-all POM project. You know the sort of thing I mean: a build-all module is a module that contains a list of other modules that get built is a specific order. I use one to build the CaptainDebug github samples and it looks like this:

<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/xsd/maven-4.0.0.xsd">
 <modelVersion>4.0.0</modelVersion>
 <groupId>com.captaindebug</groupId>
 <artifactId>build-all</artifactId>
 <version>1.0-SNAPSHOT</version>
 <packaging>pom</packaging>
 <name>The Build All Pom File</name>
 <description>Pom file that co-ordinates the whole build</description>
 <modules>
  <module>../dependency-injection-factory</module>
  <module>../powermock-tips</module>
  <module>../address</module>
  <module>../xml-tips-xmlbeans</module>
  <module>../xml-tips-jaxb</module>
  <module>../xml-tips-blog</module>
 </modules>
</project>

More recently I was working on a project that was organised slightly differently and which relied heavily upon a company wide Maven “remote” repository. The idea here was that developer A worked on Project A. When he/she was happy that the code was okay, it was deployed to the repository for use by other developers. So far, so good. Problems arose when Maven snapshots were used and the snapshot artefacts were modified often.

Developer A would build their project and deploy it to the Maven repository as a snapshot. Developer B would need this latest update for their project, but their build would fail as the required JAR was not automatically downloaded from the remote repository to their local repository and they would be stuck with an old build.

The cause may have been a problem in the way the repository was configured, or a bug somewhere, or even the way Maven is supposed to work, but the fact that developers couldn’t automatically get hold of the right versions of artifacts did cause some unnecessary aggravation and lost time for all concerned.

The fix is, once you’ve discovered it, simple. You can either delete your local repository to force its rebuild, or you can start using proper Maven version numbers instead of snapshots and do the versioning yourself. This is more effort than it’s worth as developers have to talk to one another, sending out unnecessary emails etc.

My prefered solution was to use the Maven ‘update snapshots’ command line argument. To use this argument add either --update-snapshots or -U to your command line. For example:

mvn install -U

 


Once added, this command line arg forces Maven to check all snapshots in a remote repository and update your local repository if it’s out of date.

1The remote repository in this case was Apache Archiva although I prefer Artifactory.
Published at DZone with permission of Roger Hughes, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)