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/repositories/mycomp-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]
