I think what you really want is simply a <dependency> on artifact1 and artifact2 in your artifact3 pom, not <module>../artifact1</module>. I'm a little surprised that ../ notation is even allowed in the module node, to be honest.
Then, when you build from the top, all of your projects will be built in the proper order assuming your dependencies are declared properly, and all modules will use the most recent bits of code in each module as the various artifacts are produced. If you build from a3, Maven will use the most recently built (and installed into your local repo) files from a1 and a2. It will not go into a1 and a2 to rebuild those files, however. Wayne On 8/21/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > As promised: > > I wrote on 08/21/2007 03:13:21 PM: > > > I'd like to thank you again for taking time to work with me on this. I > > have been asked to address a production problem for now but I will > attempt > > to post a concrete example from home this evening or no later than > > tomorrow morning (my TZ is GMT +5). > > > > Consider the following directory structure > > /base > /artifact1 > /artifact2 > /artifact3 > /artifact3a > > The relevant sections of /base/pom.xml look like this: > > <packaging>pom</packaging> > <modules> > <module>artifact1</module> > <module>artifact2</module> > <module>artifact3</module> > </modules> > > /base/artifact1/pom.xml and /base/artifact2/pom.xml are simple jars, so > you can call "mvn clean install" from either folder. > > The relevant sections of /base/artifact3/pom.xml look like this: > > <packaging>pom</packaging> > <modules> > <module>../artifact1</module> > <module>../artifact2</module> > <module>artifact3a</module> > </modules> > > While you can do "mvn clean install" from /base/artifact3/ you will not be > allowed to do it from /base, because the reactor won't let you visit > artifact1 and artifact2 twice. > > This is a very simplified example. Our build contains several dozen > artifacts with numerous dependencies similar to the above. Also, I am > willing to live with the fact that this may not be the best design and > that it may be easier to re-engineer the build, if that is your > recommendation. > > > Thanks again > Robert Egan > > This email message and any attachments may contain confidential, > proprietary or non-public information. The information is intended solely > for the designated recipient(s). If an addressing or transmission error > has misdirected this email, please notify the sender immediately and > destroy this email. Any review, dissemination, use or reliance upon this > information by unintended recipients is prohibited. Any opinions > expressed in this email are those of the author personally. > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
