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

Reply via email to