Intermodule Dependencies now better working in Maven 3

Found at

One of the other major improvements in Maven 3.0 is the resolution of inter-module dependencies from the current reactor build. In the past, it has been quite frustrating for users to find out that mvn install works but mvn verify sometimes fails to resolve artifacts that have just been built by a previous module, in particular when releasing a new version of their projects. Likewise, it’s hard to understand why an execution of maven-dependency-plugin:copy-dependencies succeeds to resolve artifacts from the reactor while the similar maven-dependency-plugin:copy goals fails.

As part of all the refactoring in Maven 3, a dependency resolution has been reworked to consistently check the reactor output. Apparently, the reactor output depends on the lifecycle phases that a project has completed. So if you invoke mvn compile or mvn test on a multi-module project, the loose class files from target/classes and target/test-classes, respectively, are used to create the required class path. As soon as the actual artifact has been assembled which usually happens during the package phase, dependency resolution will use this file. Last but not least, dependencies using version ranges can now be resolved from the reactor, too.

For this a short recap about reactor builds …

 parent-project (reactor)
   | ----  module-a
      | src/main/java/de/ahoehma/
      | mvn compile will create target/classes/de/ahoehma/Core.class
   | ----  module-b
      | use classes from module A
      | src/main/java/de/ahoehma/
      | Use have a dependcy to Core (module-b have a dependency to module-a)
      | mvn compile will create target/classes/de/ahoehma/Use.class

Let’s go into module-b and run mvn compile – a build error occured … can’t resolve dependency modul-a.

That’s clear … maven knows nothing about module-a right now. I can go into module-a and run mvn install to fix this „situation“.

After this I find a jar-file module-a.jar in the local maven-repository. Then the build in module-b will work. But install is not always possible … Think about API Changes, experimental code etc.  I don’t want this stuff in my local repo *g*.

For this I can run a reactor build … I go into parent and run mvn compile … that’s all. Maven will use the compile results from module-a during the build of module-b … magic 😀

[INFO] [compiler:compile {execution: default-compile}]
[DEBUG] Using compiler 'javac'.
[DEBUG] Source directories: [F:\ws_sts\parent\module-b\src\main\java]
[DEBUG] Classpath: [F:\ws_sts\parent\module-b\target\classes
[DEBUG] Output directory: F:\ws_sts\parent\module-b\target\classes
[DEBUG] Classpath:^
[DEBUG]  F:\ws_sts\parent\module-b\target\classes
[DEBUG]  F:\ws_sts\parent\module-a\target\classes
[DEBUG] Source roots:
[DEBUG]  F:\ws_sts\parent\module-b\src\main\java
[INFO] Compiling 1 source file to F:\ws_sts\parent\module-b\target\classes
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO] ------------------------------------------------------------------------
[INFO] Unnamed - de.ahoehma:parent:pom:0.0.1-SNAPSHOT ........ SUCCESS [0.758s]
[INFO] Unnamed - de.ahoehma:module-a:jar:0.0.1-SNAPSHOT ...... SUCCESS [1.590s]
[INFO] Unnamed - de.ahoehma:module-b:jar:0.0.1-SNAPSHOT ...... SUCCESS [0.637s]
[INFO] ------------------------------------------------------------------------
[INFO] ------------------------------------------------------------------------
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 3 seconds
[INFO] Finished at: Wed Dec 22 20:27:57 CET 2010
[INFO] Final Memory: 20M/128M
[INFO] ------------------------------------------------------------------------

This works in maven 2 too!