Vincent Massol wrote: >I have also been a bit troubled by this too. The issues that I see with a >parent-build-first strategy are: > >- It's the opposite of m1 > > ok
>- You can't cd to a module and build it. You need to always build the parent >first so when you do development you often forget to republish a modified >parent POM. > > irrelevant in beta-1 >- It doesn't work for aggregation when a parent does something on the result >of the children's build, like aggregating children jars in a uberjar, or >aggregating javadocs into a single javadoc, etc. Of course, as you mention, >module traversal features could be implemented every time in the plugin >itself but doesn't it means reimplementing manually the module discovery in >each plugin? > > I still think we need more work on the aggregation. For your ear case, you want to build each then take the artifacts, but for the javadoc case you just want to run the root and give it a bunch of source directories (using the reactor projects to grab source directories). >This is a complex topic though and there are lots of details to take into >account. I'm only listing here the issues that I see but I'm pretty sure >there are other issues too with doing children-build-first. But it does >sounds more logical to me to start as deep as possible and then work up to >the top level. > > Yep, I've put Bob's bug in for beta-1. >It sounds to me as if POM definitions should be done top-down and builds >bottom-up... > > Not necessary, as I mentioned. Night! - Brett --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
