Very nice description of the process.
Is there any place on the Maven site that this could be added or
integrated into existing content?
Ron
On 21/07/2011 9:16 AM, Jason van Zyl wrote:
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: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
