Hi David, > The fact is, when I ensured that both the local and intranet repo is > EMPTY of build artifacts, including the parent pom, the child modules > fail to build because they can't find the parent pom, which just > resides in the parent directory of each child module.
I have never had that problem with multi-module projects that use a combined parent/aggregator in the top-level directory. This sounds like a bug to me. Can you please create an SSCCE / MCVE? Then maybe the community can comment further on what is going wrong for you. Regards, Curtis -- Curtis Rueden LOCI software architect - http://loci.wisc.edu/software On Wed, Nov 30, 2016 at 7:59 PM, KARR, DAVID <[email protected]> wrote: > > -----Original Message----- > > From: Dan Tran [mailto:[email protected]] > > Sent: Wednesday, November 30, 2016 5:10 PM > > To: Maven Users List <[email protected]> > > Subject: Re: Need to fully understand bad implications of combined > > aggregator and parent pom > > > > Correct we dont ever enter relativePath. The implicit one should work > > and should never see warning that a module can't find its parent > > Uh, whatever. You're clearly disagreeing with me, so saying "correct" > just confuses things. > > The fact is, when I ensured that both the local and intranet repo is EMPTY > of build artifacts, including the parent pom, the child modules fail to > build because they can't find the parent pom, which just resides in the > parent directory of each child module. > > I never tried adding a "<relativePath>..</relativePath> to all of the > parent pom references, but I was able to get it to work by splitting out > the parent pom responsibilities into a separate child module pom, and > having all the references specify the relative path to that. > > > On Wed, Nov 30, 2016 at 4:54 PM, KARR, DAVID <[email protected]> wrote: > > > > > > -----Original Message----- > > > > From: Dan Tran [mailto:[email protected]] > > > > Sent: Wednesday, November 30, 2016 3:17 PM > > > > To: Maven Users List <[email protected]> > > > > Subject: Re: Need to fully understand bad implications of combined > > > > aggregator and parent pom > > > > > > > > I concur with Ben, aggregator module is banned at my work. Top > > > > level parent hosts all modules > > > > > > So does this mean that you utilize "relativePath" in the child > > > module's parent definitions? Otherwise, the child modules are being > > > built before the POM for the top-level POM is installed (which happens > > > at the end of the build). > > > > > > > On Wed, Nov 30, 2016 at 1:47 PM, KARR, DAVID <[email protected]> wrote: > > > > > > > > > > -----Original Message----- > > > > > > From: Stephen Connolly [mailto:[email protected]] > > > > > > Sent: Wednesday, November 30, 2016 1:01 PM > > > > > > To: Maven Users List <[email protected]> > > > > > > Subject: Re: Need to fully understand bad implications of > > > > > > combined aggregator and parent pom > > > > > > > > > > > > You do have relativePath set correctly for the separate parent > > > > > > from aggregator? > > > > > > > > > > Not sure whether you're addressing Benson or me, but setting > > > > > relativePath is definitely a requirement, and I think the error > > > > > message you get is pretty clear when you don’t have it, so I > > > > > imagine > > > > that's not Benson's issue. > > > > > > > > > > In my case, I did some cut/pasting and some global replaces to > > > > > separate the POM into parent and aggregator, and now my build > > > > > works from the top with empty repositories. > > > > > > > > > > I don't use the site plugin. > > > > > > > > > > > On Wed 30 Nov 2016 at 03:28, Benson Margulies > > > > > > <[email protected]> > > > > > > wrote: > > > > > > > > > > > > > My experience is precisely the opposite of yours. The most > > > > > > > common practice is for the parent to be the aggregator; it's > > > > > > > hard to get the site plugin, for example, to work right with > > > > > > > your preferred structure where they are different. > > > > > > > > > > > > > > I have built many projects with the the one-parent structure, > > > > > > > and they typically have interdependencies between the modules, > > > > > > > and they work fine. Can you boil this down to a failing case > > > > > > > on github? Can you share some poms? > > > > > > > > > > > > > > > > > > > > > On Tue, Nov 29, 2016 at 9:19 PM, KARR, DAVID <[email protected]> > > > > wrote: > > > > > > > > A while ago, I started working on an existing project with > > > > > > > > many > > > > > > > developers. The codebase has a large multi-project Maven > > build. > > > > > > > The top directory is both an "aggregator" and "parent" POM, as > > > > > > > it has a > > > > > > "modules" > > > > > > > list, and all of the child modules have it as their parent > > > > > > > POM, for dependencies and plugins. > > > > > > > > > > > > > > > > I've always believed this is a defective architecture. I > > > > > > > > believe that > > > > > > > the top-level directory should have an "aggregator" POM that > > > > > > > just lists the modules to build, and a subdirectory of the > > > > > > > top-level directory should have a project that just defines > > > > > > > the parent POM, which defines dependencies and plugins for > > subprojects to use. > > > > > > > > > > > > > > > > Although I feel this is a "cleaner" architecture, I've never > > > > > > > > been able > > > > > > > to cite specific problems with the other approach, besides the > > > > > > > fact that module changes and dependency/plugin changes go in > > > > > > > the same file, which is still a "cleanliness" argument. > > > > > > > > > > > > > > > > Today I think I saw a real reason why the present > > > > > > > > architecture is a > > > > > > > problem, but I need to be certain the problem I'm seeing is > > > > > > > caused by this, and that the better architecture fixes this > > > > > > > problem, and whether there is a simple workaround in the > > meantime. > > > > > > > > > > > > > > > > I've been modifying the build to use a completely new > > > > > > > > intranet maven > > > > > > > repo and completely different groupids for the build > > artifacts. > > > > > > > > > > > > > > > > I saw errors like this (with elisions): > > > > > > > > ----------------------- > > > > > > > > [INFO] Reactor Summary: > > > > > > > > [INFO] > > > > > > > > [INFO] big-parent ......................................... > > > > > > > > FAILURE [ > > > > > > > 5.230 s] > > > > > > > > [INFO] some-other-module................................... > > > > > > > > SKIPPED [INFO] > > > > > > > > another-module...................................... SKIPPED > > > > > > > > [INFO] > > > > > > > > .....................................................SKIPPED > > > > > > > > [INFO] > > > > > > > -------------------------------------------------------------- > > > > > > > ---- > > > > > > > ---- > > > > > > > -- > > > > > > > > [INFO] BUILD FAILURE > > > > > > > > [INFO] > > > > > > > -------------------------------------------------------------- > > > > > > > ---- > > > > > > > ---- > > > > > > > -- > > > > > > > > [INFO] Total time: 8.063 s > > > > > > > > [INFO] Finished at: 2016-11-29T16:23:36-08:00 [INFO] Final > > > > Memory: > > > > > > > > 41M/1093M [INFO] > > > > > > > -------------------------------------------------------------- > > > > > > > ---- > > > > > > > ---- > > > > > > > -- > > > > > > > > [ERROR] Failed to execute goal on project some-other-module: > > > > > > > > Could not > > > > > > > resolve dependencies for project > > > > > > > com.mycomp.detsusl:some-other-module:bundle:2.0.0-SNAPSHOT: > > > > > > > Could not find artifact > > > > > > > com.mycomp.detsusl:another-module:jar:2.0.0-SNAPSHOT in > > > > > > > mycomp-public-group ( > > > > > > > http://mavencentral.it.mycomp.com:8084/nexus/content/repositor > > > > > > > ies/ > > > > > > > myco > > > > > > > mp-public-group/) > > > > > > > -> [Help 1] > > > > > > > > [ERROR] > > > > > > > > --------------- > > > > > > > > > > > > > > > > The "big-parent" module is the top-level directory that is > > > > > > > > both the > > > > > > > aggregator and parent pom. > > > > > > > > > > > > > > > > Conceptually, I think this is happening because Maven is > > > > > > > > trying to > > > > > > > evaluate dependencies before those dependencies are built. > > > > > > > Again, I think the "separated" architecture will resolve this, > > > > > > > but before I implement that, I need to understand exactly what > > > > > > > is going on > > > > here. > > > > > > > > > > > > > > > > In my local workspace, I got around this by simply "cd"ing > > > > > > > > to the > > > > > > > "another-module" directory and doing a "mvn install", then > > > > > > > "cd"ing to "some-other-module", doing the same, and then doing > > > > > > > the same again at the top level. The reality was messier than > > > > > > > this, because I had quite a few modules that I had to build > > manually this way. > > > > > > > > > > > > > > > > Assuming I'm right that separating the "parent" function > > > > > > > > from the > > > > > > > "aggregator" function would resolve this, can someone explain > > > > > > > exactly what is happening here, how my assumed solution would > > > > > > > resolve this, and whether there's a cleaner temporary > > > > > > > workaround besides "cd"ing into each directory to do a > > separate install? > > > > > > > > > > > > > > > > ------------------------------------------------------------ > > > > > > > > ---- > > > > > > > > ---- > > > > > > > > - To unsubscribe, e-mail: [email protected] > > > > > > > > For additional commands, e-mail: [email protected] > > > > > > > > > > > > > > > > > > > > > > -------------------------------------------------------------- > > > > > > > ---- > > > > > > > --- To unsubscribe, e-mail: [email protected] > > > > > > > For additional commands, e-mail: [email protected] > > > > > > > > > > > > > > -- > > > > > > Sent from my phone > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [email protected] > > > For additional commands, e-mail: [email protected] > > > >
