Re: assembly best practices (was: Practice of releasing small changes before incorporation into a build)

[Brett Porter <br...@apache.org>]

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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: assembly best practices (was: Practice of releasing small changes before incorporation into a build)

[Brett Porter <br...@apache.org>]

Yeah, I hadn't made it to my second cup of coffee so I didn't  
remember we had the @aggregator tag for this purpose, so using  
assembly:attached *should* work for this purpose. But I don't think  
it properly draws in the modules so it's purely an assembly plugin  
feature.

- Brett

On 18/06/2007, at 11:51 AM, Wendy Smoak wrote:

> On 6/17/07, Brett Porter <br...@apache.org> wrote:
>
>> 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've never been successful with an assembly at the root because I've
> always had to jump through hoops to get the right dependencies and
> versions into the -bin assembly.
>
> -- 
> Wendy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: assembly best practices (was: Practice of releasing small changes before incorporation into a build)

[Wendy Smoak <ws...@gmail.com>]

On 6/17/07, Brett Porter <br...@apache.org> wrote:

> 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've never been successful with an assembly at the root because I've
always had to jump through hoops to get the right dependencies and
versions into the -bin assembly.

-- 
Wendy

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org