On 18/06/2007, at 11:33 AM, Jason van Zyl wrote:
I think we also have to deal with the asymmetry in that we make the
source assembly from the root, and then do weird wiggling. In Maven
I think we should have the assemblies at the top-level but this
leads other problems with the assembly plugin. Allowing the
assembly plugin to attach with a different artifactId is what is
done in the shade plugin and I think it's a valid use but in this
case I think it's a work around. Or we simply call the module that
contains the assembly be named what the assembly is to be named.
Still pondering.
I remember pushing for assemblies at the root in the past, but later
agreeing it wasn't best practice because of the lifecycle
inconsistency (the root project must be first in the reactor to
install the pom, but must be last in the reactor if it is producing
an assembly that aggregates built content).
I very much like using the root as an aggregation point (it's the
only sensible way to make a source assembly, and it would certainly
be better to have the binary assembly in the same place).
So it seems like:
- current best practice is to aggregate using dependencies under a
module
- suggested best practice is to aggregate at root, and so this must
be added to the architectural goals
A possible way to achieve this is to execute the lifecycle *both*
before and after modules in a project that has them, binding
differently each time and be able to configure which (default to
before as is the case now, but add a flag to bind new plugins after-
modules). This needs a lot more thought, just throwing it out there
for starters.
- Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
