I concur with Ben, aggregator module is banned at my work. Top level parent hosts all modules
On Wed, Nov 30, 2016 at 1:47 PM, KARR, DAVID <dk0...@att.com> wrote: > > -----Original Message----- > > From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com] > > Sent: Wednesday, November 30, 2016 1:01 PM > > To: Maven Users List <users@maven.apache.org> > > 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 <bimargul...@gmail.com> > > 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 <dk0...@att.com> 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/repositories/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: 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 > > > > > > -- > > Sent from my phone >
