maven-m2-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brett Porter <br...@apache.org>
Subject Re: Problem with phase lifecycle
Date Thu, 03 Mar 2005 10:57:37 GMT
Emmanuel Venisse wrote:

>Done. It's a very sample mojo that doesn't work. I'm certainly missing
>something.
>  
>
cool - I'll take a look. There may still be bugs.

>>Ok, so there are two alternatives:
>>- all archiving mojos extend the jar mojo
>>- we put this code into a separate maven archiving library (or make it
>>part of maven-core?).
>>    
>>
>
>I prefer the second solution (maven-archiver). Put it in maven-core isn't
>the best place.
>  
>
I agree.

>  
>
>>Is addTaggedDependencies selecting everything with a certain set of
>>properties? Nothing has been completely discussed or agreed yet, but I'm
>>thinking that can be handled by the artifact handler automatically. So
>>this function may or may not be necessary.
>>    
>>
>
>Yes like "war.bundle" or "ear.bundle" for add or not a dependencies in the
>resultant archive.
>Add this feaures in artifact handler is certainly the best place for verify
>f a dependency has or not a specific property.
>  
>
Actually, I'm thinking that the properties won't be needed (except to
override the default behaviour). Generally you want everything except
your build and test dependencies, which will be specified differently.

>>Is war:war pulling in its sources as is (ie jarring from target/classes,
>>src/main/webapp, etc), or is it building up the exploded war:webapp in
>>target, then jarring that like m1? I believe it can be more effecient by
>>pulling them all in, if possible. If it is not posssible - is it
>>necessary to distinguish?
>>    
>>
>
>Yes, and I'm agree with Michal comment.
>In a development phase, a lot of user use only the war:webapp for generate
>an exploded webapp for test it in their app server without restart it.
>  
>
Definitely, all I was wondering was whether we should just war it anyway
- but as Michal said some people might have 20mb wars.

>>Here's a different thought: what if war:war was the only goal, and a
>>property controlled whether it was archived or exploded?
>>
>><plugin>
>>  <id>war</id>
>>  <configuration>
>>    <exploded>true</exploded>
>>  </configuration>
>></plugin>
>>
>>The default would be false, but if true, m2 package would be like
>>war:webapp. m2 -Dwar.exploded=false could be used to change it on the fly.
>>    
>>
I'd still consider this an option - what do you think?

>>No, I don't like this. What is really different about the pre-compile
>>and compile stage?
>>    
>>
>
>In a pre-compile phase, we can add a mojo for source modification for
>example.
>It's very similar to a pre/post goal but applied to an complete phase.
>  
>
Sorry, my question wasn't very good. I just mean that pre/post is very
arbitrary. If there is a reason to split it because it isn't a packaging
step, then call it something different (assemble, as Michal said).

- Brett

Mime
View raw message