Re: Removing plugins from a lifecycle, programmatically or otherwise

[jallen <jo...@hotmail.com>]

dig, no one?


jallen wrote:
> 
> Dear all,
> 
> The existing clover plugin forks off its own lifecycle so it can run its
> instrumentInternal mojo in a new lifecycle and so it can try and prevent
> any test failures from breaking the forked build: 
> 
> <lifecycles>
>   <lifecycle>
>     <id>clover</id>
>     <phases>
>       <phase>
>         <id>validate</id>
>         <executions>
>           <execution>
>             <configuration>
>              
> <cloverOutputDirectory>${project.build.directory}/clover</cloverOutputDirectory>
>              
> <cloverDatabase>${project.build.directory}/clover/clover.db</cloverDatabase>
>             </configuration>
>             <goals>
>               <goal>instrumentInternal</goal>
>             </goals>
>           </execution>
>         </executions>
>       </phase>
> 
>       <!-- This below is a HACK. It tries to prevent the build from
> stopping in
>            case of build failures as we could still like to generate
> Clover
>            reports even if it happens. The Clover plugin cannot know about
> all
>            plugins that can execute and fail the build and moreover which
> can be
>            bound to any phase by the user. A better solution would be for
> Maven
>            to have a flag that says "continue the build even in case of
>            failures". -->
>       <phase>
>         <id>test</id>
>         <configuration>
>           <testFailureIgnore>true</testFailureIgnore>
>         </configuration>
>       </phase>
>       <phase>
>         <id>integration-test</id>
>         <configuration>
>           <testFailureIgnore>true</testFailureIgnore>
>         </configuration>
>       </phase>
> 
>     </phases>
>   </lifecycle>
> </lifecycles>
> 
> 
> However with this approach we find you get big problems when the build has
> got other plugins bound to it, especially code generation plugins and code
> checking plugins.
> 
> So what we would like to do is programmatically or otherwise remove
> certain plugins from this forked lifecycle. I guess programmatically might
> not be possible as we don't get a chance to run any code before this
> forked lifecycle is run but can we do it via changing the lifecycle
> itself? Bear in mind we cant ask the other plugins not to run via
> configuration parameters are we don't own the code for them and the
> majority to honour a 'skip' parameter anyway.
> 
> I think we may have to muck around with the components.xml but is there a
> way to use a different component mapping without it being led by the
> packaging type? 
> 
> Has anyone got any bright ideas on how we can crack this problem?
> 
> The goal is to just run clover:instrumentInternal, resources:resources,
> compiler:compile and surefire:test and nothing much else.
> 
> Kind regards,
> 
> John
> 

-- 
View this message in context: http://www.nabble.com/Removing-plugins-from-a-lifecycle%2C-programmatically-or-otherwise-tf4467756s177.html#a13120738
Sent from the Maven Developers mailing list archive at Nabble.com.


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