With all due respect, why do you care? The parent project is only a POM... It effectively declares the structure of the project. If there is a core piece of logic that all other modules are built around, you define a module for that logic and then declare it as a dependency of all other modules.
I think you are misinterpreting the role of the parent - there is no code involved. Keith -----Original Message----- From: dennis.mendel...@rbs.com [mailto:dennis.mendel...@rbs.com] Sent: Tuesday, September 22, 2009 12:57 PM To: users@maven.apache.org Subject: RE: Help with (sibling directory) modules Indeed the projects share common dependencies. It seems to me, though, that you conflate the "structural/functional" relationships referred to by Stephen below (or is that perhaps imposed by Maven?). Surely a parent POM containing common dependencies can live in $DEV_ROOT/parent, without requiring A, B, etc. to move underneath $DEV_ROOT/parent? Dennis -----Original Message----- From: Barlow, Keith [mailto:keith_bar...@cable.comcast.com] Sent: 22 September 2009 17:38 To: Maven Users List Subject: RE: Help with (sibling directory) modules If those projects have no dependencies upon each other... than you are best off declaring them as separate projects - you will then be able to check them out and build them as necessary. If those projects share common dependencies, you will want to establish as "parent" project which will declare the common configurations in its POM and then create the A and B as modules within that parent project. This will allow you to check out the entire branch and build modules as necessary while managing the dependencies effectively. Modules A and B will inherit the common configuration settings from the parent. Keith -----Original Message----- From: dennis.mendel...@rbs.com [mailto:dennis.mendel...@rbs.com] Sent: Tuesday, September 22, 2009 12:32 PM To: users@maven.apache.org Subject: RE: Help with (sibling directory) modules Let me be more explicit about my requirements.. I have a set of legacy projects, each belonging within a sub-directory of $DEV_ROOT, say: $DEV_ROOT/A; $DEV_ROOT/B; etc. >From an empty $DEV_ROOT, I would like to be able to checkout from SCM a POM >(which lists A, B, etc. as modules), into either $DEV_ROOT, or >$DEV_ROOT/aggregation, say, and then run a Maven command that will checkout >and build all module code. It's not obvious to me that this is doable, and my initial investigations with scm:checkout and scm:bootstrap have not been very fruitful. Dennis -----Original Message----- From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com] Sent: 22 September 2009 17:10 To: Maven Users List Subject: Re: Help with (sibling directory) modules The documentation is correct w.r.t. <modules> sections however, this does not apply to <parent> sections. The <parent> section does not have to contain any <modules> at all. In fact some people maintain that it is better if the parent-child relationship is "functional" while the modules-child relationship is "structural" The other thing is that once you get the above, you will see that there is nothing stopping you from doing <modules> <module>../foobar</module> </modules> _however_ once you do that, releasing with the maven release plugin can become a lot more "fun" which is why people recommend not using ../ in <module>s and putting a "structural" arrangement for aggregation, i.e. aggregation is for things that will be released together. inheritance is for things that share "functionality" -Stephen 2009/9/22 Barlow, Keith <keith_bar...@cable.comcast.com>: > The documentation is correct... the structure must follow a predefined > layout. Maven uses convention over configuration and requires you to > use a defined directory structure (it's possible customize in some > cases but not worth it). Why you would want a root level pom in a > sibling directory is beyond me but I would recommend following the > prescribed patterns. > > Keith > > -----Original Message----- > From: dennis.mendel...@rbs.com [mailto:dennis.mendel...@rbs.com] > Sent: Tuesday, September 22, 2009 10:02 AM > To: users@maven.apache.org > Subject: Help with (sibling directory) modules > > Hello, > > Could someone please confirm or dismiss (preferably the latter) the > following, from > http://www.sonatype.com/books/maven-book/reference/pom-relationships-s > ec t-multi-module.html (Maven: The Definitive Guide): > > "The directory structure on the file system would also mirror the > module relationships", i.e. module code must always live underneath > the root of the project whose POM lists the module. > > I would like the POM listing the modules to live in a sibling > directory to the module root directories themselves, not in a parent > directory. If that were not possible, I would consider it an > unfortunate limitation imposed by Maven - a build system would ideally > not enforce the source's layout on the filesystem. > > Thanks, > > Dennis > > Dennis Mendelson > Java Developer (Credit Risk BAU) > RBS Global Banking & Markets > Bankside 2, 90-100 Southwark Street, London SE1 0SW, United Kingdom > Office: +44 20 3361 9227 | Mobile: +44 7717 222 690 > > > > ********************************************************************** > ** > *********** > The Royal Bank of Scotland plc. Registered in Scotland No 90312. > Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB. > Authorised and regulated by the Financial Services Authority. > > This e-mail message is confidential and for use by the addressee only. > If the message is received by anyone other than the addressee, please > return the message to the sender by replying to it and then delete the > message from your computer. Internet e-mails are not necessarily > secure. The Royal Bank of Scotland plc does not accept responsibility > for changes made to this message after it was sent. > > Whilst all reasonable care has been taken to avoid the transmission of > viruses, it is the responsibility of the recipient to ensure that the > onward transmission, opening or use of this message and any > attachments will not adversely affect its systems or data. No > responsibility is accepted by The Royal Bank of Scotland plc in this > regard and the recipient should carry > > out such virus and other checks as it considers appropriate. > > Visit our website at www.rbs.com > > ********************************************************************** > ** > *********** > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
