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: [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#a11749038 Sent from the Maven - Users mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
