Vincent Massol wrote:

>>Also requires the hooks to remove the files beforehand. But sounds good
>>    
>>
>
>Yes, I still don't understand how you do this in m2... Is this goal
>aliasing?
>  
>
I just meant extra configuration for the plugin.

>I could give it a try. I'd rather name is something like "filechecker"
>rather than verifier which is too generic. 
>  
>
Well, it could be used to verify more complicated assumptions later on...

> 
>  
>
>>Ideally, the verifier could be converted to a mojo and used in both the
>>bootstrap and the m2 integration test phase for plugins.
>>    
>>
>
>I'm not too familiar with the existing code.
>  
>
I think you'll find it fairly straightforward.

> 
>
>Ok cool, found it. Ok, so this where the default bindings are. So the
>different build types from my previous email could actually be different
>configurations of org.apache.maven.lifecycle.DefaultLifecycleExecutor.
>  
>
Different build types? Which was that from?

>I guess there's currently no way for a user to define a custom lifecycle,
>right? Maybe goal aliasing could be combined with this to give something
>like:
>  
>
That's not really the intention. You can bind your goals to any of the
phases, but we don't allow changing the lifecycle or unbinding any of
the default goals.

>Maybe the m1 model is actually the simplest (where there are no phases and
>the user decides on the ordering of the goals)?
>  
>
What is not simple about this is figuring out what that order is when
you weren't the one defining it. The lifecycle is much simpler to
understand IMO.

>Yep. This integration testing phase would be required for this
>verifier|filechecker plugin to work.
>  
>
I'll add it.

> 1/ the said plugin would first need to be bound to the right phase. For
> example let's imagine there is a clover:instrument goal bound to the
> generate-sources phase and a clover:compile goal bound to the compile phase.
> 
> 2/ then in your pom.xml you would specify:
> 
> 3/ Whenever the user would type something like "m2 compile" it would execute
> the 2 goals.
> 
> Is that correct?

Right... but I don't know that you need clover:compile. If the instrument adds 
it to the source roots, compiler:compile will compile it to target/classes.

So I'm not sure what you really want here... do you want it compiled to the 
test classes (add it to test source roots), main classes (add it to compile 
source roots), or a whole new output directory?

The last isn't currently possible - you'd either need to configure an 
additional compiler in POM (like you have), but it might be better to have a 
generic case (where clover:instrument can add a whole new source root + output 
directory mapping to the project).

> 
> Question: how is the order defined between compiler:compile and
> clover:compile in this case?
> 

You can't, other than the order the plugins are declared in the POM.

Cheers,
Brett

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to