Hello, I use the combined aggregator/parent pom as well. While multiple poms may be cleaner because of separation of concerns, you might easily end in duplications for e.g. plugin definitions, which is a shame as well.
Regards Mirko -- Sent from my mobile Am 05.12.2016 10:56 schrieb "Sander Verhagen" <san...@sanderverhagen.net>: > Simple and easy may be in the eye of the beholder. I get a lot of your > points (except for the cycles breaking your build, I'm not recognizing > that), but my environment is just dramatically different, and the things > that you are describing as necessary for your environment, would be > unneeded complexity for mine. We have a lot more entirely separate > projects, each of which with their own (smaller) constellation (ancestry) > of Maven projects. There's a company POM. Each project has a parent POM, > that inherits the company POM, and yes, it's an aggregator too. That's > never a problem, because the child projects are all unique and different, > and aside from a few shared plugin configurations, that we are perfectly > happy to have in the company POM, and a few enforcer rules that we are > happy to share across the entire project, all the real meat is in the leaf > node POM files. I don’t know what JSP compilation you speak of, nor do we > have any significant WAR configuration to be shared across modules. I > currently have 716 POM files checked out locally (just a quick "find"), > just to give you some feeling that my application of Maven isn't just > trivial. But it is DIFFERENT than yours. And I like my shared > aggregator/parent POMs. Maybe if it hadn't been designed like this, by > Maven, for many years now as it is, whatever the world would look like > would've been fine too, but now I'm fond of this approach, to be honest :) > > One more note, I have learned to be sparse on what to put into the > inheritance hierarchy (composition over inheritance, that good stuff), so > our parent POMs are also a lot leaner than what I've seen (myself and > others do) in the past. Something like this may play into your observations > also. > > Thanks for everyone's perspective on this, it's interesting! > > > Sander Verhagen > [ san...@sanderverhagen.net ] > > NOTICE: my e-mail address has changed. Please remove verha...@sander.com > now and start using san...@sanderverhagen.net from now on. Please update > your address book. Thank you! > > -----Original Message----- > From: Hilco Wijbenga [mailto:hilco.wijbe...@gmail.com] > Sent: Sunday, December 4, 2016 17:16 > To: Maven Users List <users@maven.apache.org> > Subject: Re: Need to fully understand bad implications of combined > aggregator and parent pom > > Indeed, combining the parent and aggregator concerns in one POM is not a > good idea. I would go so far as to call it an anti-pattern. A very common > one, unfortunately. > > First, you get a cycle per module. Cycles are never a good thing, though > sometimes they are unavoidable. Maven seems to be fine with this particular > type of cycle but you still get strange behaviour on occasion. A build may > break (especially when starting with an empty > repository) with a strange error message but a second attempt may succeed. > That's also (probably) why it is usually not recognised as a problem. If > the second build succeeds you tend to shrug your shoulders and move on. > > Let's say you have an enormous Java file of 10,000 lines of code. I don't > think anyone would consider that good design. Similarly, if you have a > single project with some 4,000 Java files. Again, I don't think anyone > would consider that an example of good design. In both cases, we would > argue that it needs to be broken up because, clearly, separate/independent > concerns have been conflated. And it is all just too hard to understand, > too hard to test, and too hard to maintain. > > So why would it be a good idea to put all POM related concerns in one > place? Especially when it comes to modules, they are *only* relevant at > compile time. There is absolutely no reason to know about this at any other > time. In fact, my aggregator POMs have a version "modules" > (that looks nice in the build output) that never changes and they all set > <maven.deploy.skip>. > > But it goes beyond that. If you have a JAR project and a WAR project then > it makes sense to have a separate parent-jar-pom and parent-war-pom. The > parent-jar-pom would only need to know about compiling Java code and > putting it in a JAR. Very simple. The parent-war-pom, however, would need > to know about JSP compilation > (e.g.) and how to run the WAR with Tomcat or Jetty. Perhaps the > parent-war-pom extends the parent-jar-pom but in any case there is no need > for this additional complexity to be in the parent-jar-pom. > > I think the core difference between these philosophies is choosing between > "easy" and "simple". It may be easy to put everything in one POM, but it > will cost you in maintenance effort. It takes more effort and thought to > simplify things and try and separate independent concerns into separate > POMs but your maintenance burden will be lighter. Why? Because if you > change something about the JSP compilation only your WAR projects will be > affected. Such cause and effect is easy to explain and understand: it's > simple. :-) Remember, we're not just going to have to explain this to our > colleagues but also (e.g.) our manager and the change control board. > > With a single parent-pom, naturally, you could simply not upgrade your JAR > project to the latest parent POM (the one with the JSP compilation > changes) but then you are forcing your maintenance developers to know the > difference between multiple versions of the parent POM. And this very > quickly becomes more than 2 and for more than 1 project. This is your > typical "throw it over the fence" approach. Having been on the other side > of that fence, I would consider that "not nice". > > On 2 December 2016 at 04:02, João Cabrita <joao.r.cabr...@gmail.com> > wrote: > > My experience has been that combining parent and aggregator concerns > > into the root module causes trouble for "aggregator-style" goals like > > "javadoc-aggregate" that depend on artifacts generated by the submodules. > > > > The reason seems to be that, when using such goals, there is a cyclic > > dependency: the parent/aggregator depends on its submodules for the > > artifacts and the submodules depend on the parent/aggregator for it's > > configuration. > > This leads me to believe that filing this as a bug isn't entirely > correct. > > > > To be more specific, for a module A that is both parent and aggregator > > of submodules B and C, the build order is A B C. > > When A is just an aggregator and B, C and P are submodules of A, with > > P being parent of B and C, the build order is P B C A. > > Notice that the aggregator has moved from the start of the list > > (because the children depend on it) to the end (because they no longer > do). > > > > João Cabrita > > > > On 1 December 2016 at 04:26, Curtis Rueden <ctrue...@wisc.edu> wrote: > > > >> 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 <dk0...@att.com> wrote: > >> > >> > > -----Original Message----- > >> > > From: Dan Tran [mailto:dant...@gmail.com] > >> > > Sent: Wednesday, November 30, 2016 5:10 PM > >> > > To: Maven Users List <users@maven.apache.org> > >> > > 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 <dk0...@att.com> > wrote: > >> > > > >> > > > > -----Original Message----- > >> > > > > From: Dan Tran [mailto:dant...@gmail.com] > >> > > > > Sent: Wednesday, November 30, 2016 3:17 PM > >> > > > > To: Maven Users List <users@maven.apache.org> > >> > > > > 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 <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/ > >> 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: users-unsubscribe@maven. > >> apache.org > >> > > > > > > > > For additional commands, e-mail: > >> users-h...@maven.apache.org > >> > > > > > > > > > >> > > > > > > > > >> > > > > > > > ------------------------------------------------------- > >> > > > > > > > ----- > >> -- > >> > > > > > > > ---- > >> > > > > > > > --- To unsubscribe, e-mail: users-unsubscribe@maven. > >> apache.org > >> > > > > > > > For additional commands, e-mail: > >> > > > > > > > users-h...@maven.apache.org > >> > > > > > > > > >> > > > > > > > -- > >> > > > > > > Sent from my phone > >> > > > > > > >> > > > > >> > > > ------------------------------------------------------------ > >> --------- > >> > > > 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 > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org >
