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: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> > > -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
