Kane, Dependency resolution in Maven is controlled by the specification of dependencies, where those dependencies are found in any number of repositories.
When you build a product, it generally consists of N Maven projects and may look something like Maven itself: https://github.com/apache/maven-3 The specification of modules is a build-time mechanism for creating what we call the reactor, and you can think of the reactor as a type of repository. The search order when building a product on disk is: reactor local maven repository (i.e. ~/.m2/repository) remote maven repositories (i.e http://repo1.maven.org/maven2 by default) When you are building a product on disk and you have dependency relationships amongst the projects that make up your product, you want what you are currently building to be considered before consulting the local maven repository or any of the remote maven repositories specified. So if you look at the aggregator POM for Maven: https://github.com/apache/maven-3/blob/trunk/pom.xml You will see a number of modules listed. When Maven reads that POM it looks at all the modules, and for each one walks into the directory specified in the module entry, constructs the corresponding Maven Project and adds that project to the reactor. This has nothing to do with the dependency relationships that have been specified between the projects, a dependency can only be specified using the dependency element in the POM. Now the maven-core project depends on the maven-model project and while I am building on disk using a reactor the maven-model dependency for maven-core will be resolved from the reactor because it is one of the modules listed, it was added the reactor and is made available as a dependency from the reactor. You don't want maven-model to be resolved from the local repository because it may have different method signatures, be something you built 10 days agos, or there may be no version of maven-model in your local repository at all because it's the first time you're building Maven. You can think of the reactor like you do an IDE workspace. For all the projects that are related in your IDE workspace, you want those relationships to be resolved within workspace if possible. If you are building independent projects which are used in other products as third party dependencies, with Maven you typically do not link these together on disk in one giant source build. You build your projects and install them into the local maven repository and that is used as the mediation point from which your products can consume those dependencies. If I'm working on Maven and Aether on the command line I know that Maven depends on Aether. So I do some work in Aether and do a "mvn clean install" which puts Aether in the local maven repository. Then I move to Maven on disk, and do a "mvn clean install" and the new version of Aether I just built will be available in the local repository for consumption. If you want to work on all of these products and projects concurrently then typically you bring all of them together in an IDE workspace where they will be linked together. If I'm working on Maven and Aether for example, I can have them both loaded in Eclipse and work/debug on them together, but we do not link these builds up together on the CLI because they are independent. If you want to make sure everything works together then you can use a CI system to build all your independent products and projects. Most CI systems can figure out the relationships, or allow you to specify the order in which a complex set of products and projects should be built and tested. Maven's dependency resolution mechanism knows nothing about modules. To recap the modules listed in an aggregator, are consulted to create a reactor of projects which is a type of repository from which dependencies can be resolved. The key point being that modules contribute the construction of a type of repository made available to the dependency resolution process, they do not imply a dependency relationship. On Jul 20, 2011, at 1:58 PM, kanesee wrote: > Hi Wayne, > > Yes, I understand I don't have to have to depend on C from product X, but do > I need to include it as a module? > > -Kane > > -- > View this message in context: > http://maven.40175.n5.nabble.com/Misunderstanding-modules-Two-or-more-projects-in-the-reactor-have-the-same-identifier-tp4614001p4616738.html > Sent from the Maven - Users mailing list archive at Nabble.com. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > Thanks, Jason ---------------------------------------------------------- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl --------------------------------------------------------- We know what we are, but know not what we may be. -- Shakespeare
