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]