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]
