Hi kapiland,
kapilanand schrieb:
I am new to maven. I am using maven 2.0.7.
I have a multi-module project A which defines the dependencyManagement
entries for the contained modules, say A1, A2, A3.
But as suggested in books and sites I also have inheritance relation between
the poms of the modules to the parent module, that is A's pom is parent of
A1's, A2's and A3's poms.
This works fine, but then it is not much of use since this grouping helps me
only in building them together.
I. Project Aggregation vs. Inheritance
Project aggregation (the <modules/> tag) and project inheritance
(<parent/>) are two distinct aspects. Project aggregation is for
building a group of related projects together. The child modules don't
know anything about the aggregation pom.
Whereas project inheritance is used to define common sets of
configuration for a group of projects. So for example if you have a
couple of projects that all have a dependency to the same library you
could have a parent pom with this dependency declared and let the actual
projects inherit from this pom.
These two aspects can be combined in one top-level pom for a project
(and this makes sense in many projects) but this isn't a must. Think for
example of a parent pom for all EJB projects. This parent pom will be
usefull not just for one application/project but for every J2EE project
you have. So you pobably don't want to duplicate the definitions in the
parent pom in every projects top-level pom but instead have a distinct
parent pom the every EJB projects inherits from.
II. <dependencyManagement/> vs. <dependencies/>
I think you missunderstood the meaning of this tags. With the
<dependencies/> tag you include the dependencies in your project. When
you have a poject A that depends on project B you would include this
dependency in the <dependencies/> section of project A's pom.
If you have a group of projects all depending on B you could factor out
the dependency definition to the <dependencies/> section of the parent
pom for this projects. And all projects will inherit the dependency.
If not all projects of the group depend on B but you want to ensure that
the projects depending on B will use the same version of B you can
define that in the <dependencyManagement/> section of the parent pom:
<dependencyManagement>
<dependency>
<groupId>mygroup</groupId>
<artifactId>B</artifactId>
<version>1.0</version>
</dependency>
</dependencyManagement>
And then in the projects depending on B declare a dependency, leaving
out the version:
<dependencies>
<dependency>
<groupId>mygroup</groupId>
<artifactId>B</artifactId>
</dependency>
</dependencies>
I have another project B that depends on this multi-module project A and I
have declared a dependency of B on A with type=pom. Now this dependency is
of no use since it is not adding the child modules to the classpath of this
other project B. Neither does it allow me to add module-project dependencies
without specifying their version. (That means i have to specify the version
for each module, but then what's point of building them together as one
project)
I tried to fix this by adding child modules as dependencies of the top pom
A, but this results in cyclic dependency problem because of inheritance
relation.
Am I missing something here or is it really a win-loss situation to mix
these two features?
Hope this is clearer now after reading the above.
-Tim
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]