Hi Jesse, Unfortunately this mail from Sept was ahead of its time :)
I've reviewed, and I think most of the test stuff is being worked through with equivalent use cases. I'm sur eyou'll let us know if it doesn't cover your case. On the profiles stuff: Jesse McConnell wrote: > - plugins are getting pulled up into profiles because we want to change the > configuration of the plugin based on some conditional event, what if we have > > <build> > <plugins> > <plugin> > <configurations> > <id>qa</id> > <configuration> > <activation> > <property> > <name>env</name> > <value>development</value> > </property> > </activation> > <sourceDirectory>blah</> > </configuration> > . > . > > this would have a number of benefits...one of them being that the plugin > would fall back into the right place in the lifecycle naturally as opposed > to whent he profiles are getting activated. It is also less wordy in that I > don't have to repeat the entire plugin xml inside of each profile. Doesn't this just switch the plugin verbosity for activation verbosity? The only saving is when you have one of each, so you avoid any duplication. I think we need to address this concern when we come to rethinking the execution model for 2.1/2.2. Again, sorry for the 4 month delay on mail ;) Cheers, Brett --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
