You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by kapilanand <an...@yahoo.com> on 2007/07/20 23:15:08 UTC
pom inheritence and multi-module pom do not complement
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 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?
--
View this message in context: http://www.nabble.com/pom-inheritence-and-multi-module-pom-do-not-complement-tf4119628s177.html#a11716184
Sent from the Maven - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: pom inheritence and multi-module pom do not complement
Posted by kapilanand <an...@yahoo.com>.
This is what i finally did:
Defined two projects with type=pom.
pom 1 (build pom): define common configurations, including product version
and dependencyManagement entries. This is the base pom for all projects in
the product.
pom 2 (product aggregation pom): defines modules and also defines dependency
on the module projects. In other words this represents a product or an
aggregate of a multi-module library. This pom inherits from pom 1 and does
not define its own versions.
(ideally modules should be added to the dependency chain automatically)
A separate project that needs to use more than one modules of this product,
only declares its dependency on this product-aggregation pom project and
modules are automatically included.
Only drawback is that I have to deploy the parent build pom in a separate
build step. What I am now looking for is the way or settings to auto-deploy
the parent pom along with an inherited pom.
- kapil
kapilanand wrote:
>
> Tim, thanks for providing the detailed explanation. I am aware of the
> things that you explained.
>
>
> What I wanted to put across was that there are two use-cases that are not
> met by current support of inheritance and aggregation:
> 1) implicit or explicit inheritance of the container (aggregating pom)
> project by the module projects in a multi-module project.
> This is not that important since we can repeat the settings in each
> pom.xml and not use inheritance, but then we loose useful constraints such
> as dependencyManagement.
> The work around is to define a dummy project that will be inherited by the
> aggregated projects and the aggregating/container project, but then
> aggregating pom is not of much use except for defining modules. The build
> process will need a separate step for uploading/deploying this dummy
> parent pom to the repository. (since it cannot be treated as a module)
>
> 2) implicit or explicit dependency of container project on the module
> projects.
> Explicit is supported which is achieved by defining dependency tags for
> module projects in the aggregating/container project. But if we declare
> explicit dependency of the container on modules, modules cannot inherit
> from the container, which contradicts the first use case.
> So implicit would make more sense, as that way another project using the
> multi-module project does not need to specify dependency on each module
> explicitly along with the version number. Declaring a dependency on the
> container pom project should be enough to import all modules into the
> dependency chain.
>
> I hope I could clarify my concern.
>
> - kapil
>
>
> Tim Kettler wrote:
>>
>> 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: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>>
>
>
--
View this message in context: http://www.nabble.com/pom-inheritence-and-multi-module-pom-do-not-complement-tf4119628s177.html#a11766631
Sent from the Maven - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: pom inheritence and multi-module pom do not complement
Posted by kapilanand <an...@yahoo.com>.
Tim, thanks for providing the detailed explanation. I am aware of the things
that you explained.
What I wanted to put across was that there are two use-cases that are not
met by current support of inheritance and aggregation:
1) implicit or explicit inheritance of the container (aggregating pom)
project by the module projects in a multi-module project.
This is not that important since we can repeat the settings in each pom.xml
and not use inheritance, but then we loose useful constraints such as
dependencyManagement.
The work around is to define a dummy project that will be inherited by the
aggregated projects and the aggregating/container project, but then
aggregating pom is not of much use except for defining modules.
2) implicit or explicit dependency of container project on the module
projects.
Explicit is supported which is achieved by defining dependency tags for
module projects in the aggregating/container project. But if we declare
explicit dependency of the container on modules, modules cannot inherit from
the container, which contradicts the first use case.
So implicit would make more sense, as that way another project using the
multi-module project does not need to specify dependency on each module
explicitly along with the version number. Declaring a dependency on the
container pom project should be enough to import all modules into the
dependency chain.
I hope I could clarify my concern.
- kapil
Tim Kettler wrote:
>
> 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: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/pom-inheritence-and-multi-module-pom-do-not-complement-tf4119628s177.html#a11749038
Sent from the Maven - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: pom inheritence and multi-module pom do not complement
Posted by kapilanand <an...@yahoo.com>.
Tim, thanks for providing the detailed explanation. I am aware of the things
that you explained.
What I wanted to put across was that there are two use-cases that are not
met by current support of inheritance and aggregation:
1) implicit or explicit inheritance of the container (aggregating pom)
project by the module projects in a multi-module project.
This is not that important since we can repeat the settings in each pom.xml
and not use inheritance, but then we loose useful constraints such as
dependencyManagement.
The work around is to define a dummy project that will be inherited by the
aggregated projects and the aggregating/container project, but then
aggregating pom is not of much use except for defining modules.
2) implicit or explicit dependency of container project on the module
projects.
Implicit would make sense. That way another project using the multi-module
project does not need to specify dependency on each module explicitly along
with the version number. Declaring a dependency on the container pom project
should be enough to import all modules into the dependency chain.
I hope I could clarify my concern.
- kapil
Tim Kettler wrote:
>
> 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: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/pom-inheritence-and-multi-module-pom-do-not-complement-tf4119628s177.html#a11749038
Sent from the Maven - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: pom inheritence and multi-module pom do not complement
Posted by Tim Kettler <ti...@udo.edu>.
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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org