You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by ia...@jpmchase.com on 2006/05/01 15:26:32 UTC
Re: Explain multi-module support in M2
Simon,
This is a distinction I hadn't seen made before (though now that you point
it out, it makes sense). Any chance of getting this incorporated into the
Maven documentation somewhere?
Thanx,
Ian
It's better to be hated for who you are
than loved for who you are not
Ian D. Stewart
Appl Dev Analyst-Advisory, DCS Automation
JPMorganChase Global Technology Infrastructure
Phone: (614) 244-2564
Pager: (888) 260-0078
Simon Kitching
<skitching@apache To: Maven Users List <us...@maven.apache.org>
.org> cc:
Subject: Re: Explain multi-module support in M2
04/28/2006 07:43
PM
Please respond to
"Maven Users
List"
Hi Clifton,
Note that there are two different concepts here.
(a) A "parent pom" is a pom whose attributes are inherited by any pom
whose <parent> tag points at it.
(b) A "module pom" uses <module> tags to point at directories containing
pom files. Whenever the "module pom" is specified, the phase/goal is
executed for that pom AND every pom pointed to by it. The module poms
are first inspected to determine from their dependencies the correct
order to invoke them; the maven component that generates the
correctly-ordered set of modules is referred to as a "reactor".
[NB: I just made up the term "module pom"; maybe there's an official
term].
Often a single file fills both roles, but they can be separate.
When a pom points at a parent, it can specify a (groupId,artifactId) in
which case the parent pom is fetched from the maven repository. This
allows a module to be built even when the "parent" has not been checked
out locally; very useful. A pom can also specify a relativePath; if the
specified file actually exists locally it is used in preference. This
makes development easier as it's possible for changes to the parent pom
to take effect without running "mvn install" on it. There are no limits
at all imposed on your directory here; a child can point to any parent
it wants.
A <module> tag simply specifies a directory. Paths like
"widgets/widget1" are fine. I suspect that "../widget1" would also work
but haven't tried it. Assuming it does, there are no limitations on the
layout.
There is no mechanism that ensures that when you execute a goal in
module Z, its dependencies are all rebuilt; the latest versions of all
dependencies are just fetched from repositories. To rebuild everything,
you execute a phase/target using the "module pom".
Regards,
Simon
On Thu, 2006-04-27 at 14:15 -0400, Clifton Craig wrote:
> Hello all,
>
> I'm relatively new to Maven2 and I'd like somebody to explain the
multi-module
> support in a little more detail. We have some projects that we're
managing
> with M2. I'm not sure that I want to use multi-module support because it
> seems a little restrictive as explained on the site. However, I'm afraid
that
> I may need some of the features from mult-module support. Let me clarify.
> Take the following example: Projects A, B, C, and D. B, C, and D all
depend
> on A. C and D depend on B. The one problem (due to my lack of
understanding)
> I have is that for multi-module support to work, as I understand it, I
would
> need to reflect the module dependencies in the directory structure of the
> modules. This means a module folder would need to sit atop of its
dependency
> module folders. In my example there is no clean way (short of using
> replicating modules or icky non-x-platform symbolic links) to acheive the
> relationship in the directory structure. So it makes better sense to
layout
> all modules as peers including parent modules and folders with parent pom
> files. I'm not sure if this is supported or I'm not understanding the
> workings correctly.
>
> The other problem I have is that if my prior explanation is not accurate
how
> would we make the association evident in child modules to their parents?
In
> other words, assume I have all modules A-D laid out as peers on the
> filesystem. Also assume that there is a global module, E, that contains
> settings that are inherited by the others A-D. (E is also a peer.) If I'm
> working in the folder for B and decide to run "mvn test" or "mvn deploy",
how
> then does it know to look into the peer folder for E for inherited
settings?
> It seems to me that either some sort of reference need to be made to the
> location of E or E would need to be installed first before testing or
> deploying B. I'm sure I have some things misunderstood but could somebody
> clear things up for me?
>
> ---------------------------------------------------
> Clifton C. Craig, Software Engineer
> Intelligent Computer Systems - A Division of GBG
> ccc@icsaward.com
> ccraig@gbg.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org