(note, this might a little disjointed to get through...but I think the last part might actually contain a suitable idea regarding profiles, if it hasn't already been discussed)
I think I have covered this in part with at least kenney, jdcasey and brett on irc...and brett mentioned I ought to write up a bit about the problem space to the dev mailing list for some offline discussion. first, my specific use case involves the wsd2ljava plugin and what the underlying wsdl2java axis tool gives you.... wsdl2java basically takes a wsdl file (xml) and processes out a series of stubs, skeletons and optionally some junit tests that test the webservice. at the moment I have been hacking on the plugin so it integrates into the m2 doctrine a little cleaner, for example the unit tests that are created are now moved to /target/generated-test-sources and registered with the project with addTestCompileSourceRoot(). herein lays the basic problem.. - the wsdl2java plugin runs in generate-sources phase, but produces things that are logically supposed to be a product of the generate-test-sources phase... - registering those generated test sources has a deeper meaning in that it implys that surefire will execute those unit tests and fail if the external resource is down... - this means that we need to conditionally determine if that resource ought to be added to the testing source based on if some external resource is available..which rather defeats the m2 goal of what a unit test is (run fast, run often) - so the source should perhaps be a part of an integration phase, but anyway you look at it...that plugin needs to know to do all that at the time the plugin itself is executed, which for me is in the profile resolution because this plugin has different source directories for wsdl files since development, qa, production servers are all different urls and the corresponding wsdl files are different.. the more general problem is in trying to weave a cruddy situation like mine into the more rigidly defined m2 lifecycle one quick, possibly large can of worms solution would be have a set of lifecycle plugins or some deal that provided a means to pull the cruddy stuff out of the lifecycle poluting plugin like mine...but that doesn't get us too much farther along since they wouldn't be able to do conditionally useful things like testing if that wsdl url was active before deciding do whatever it was told to (like call addTestCompileSourceRoot()). then the lifecycle could happily run these integration tests...or perhaps the definition of an integration test implies that external resource _is_ up and it should always try it. maybe this isn't that big of a problem if we have a formalized integration testing cycle that could be set through MavenProject a la unit tests...I know that has been discussed a couple of times on irc. now perhaps that actually is the the more formal solution to this situation, which I guess I happily embrace atm...that unit tests are not what these test cases that wsdl2java actually produces and that the whole thing needs to be shoved off to another phase in the lifecycle. It should be obvious though that while I have rambled on through this I do show how I am trying to corrupt the spirit of what a profile is...which is what really prompted this whole mess of an email. I have environmentally affected plugins that do a lot of work, more raw work perhaps then they ought to...but when you look at it the only reason I am corrupting profiles in this way is to pass different configuration options to plugins...profiles just serve as the easiest mechanism to do it atm...And I will not be the only one that abuses the hell out of them to get what I want done :) Althrough writing all this has got me thinking of a potential solution so I'll leave on a positive note if you actually make it this far. - 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. I think that has the potential to address what I think will be the most common cases people will start flocking to profiles. It also might allow profiles to stop accepting plugins at all, or at least any plugin that is assigned to a phase other then @profile-resolution...if something isn't done then you can already see the mess I have been trying to make out of profiles :P maybe a fun little benefit could be 'm2 plugin:phase:configuration' as well if you wanted to force it...but that is iffy I suppose :) thoughts? btw, I can't remember if I am on this mailing list or if I was just on [EMAIL PROTECTED] kindly keep me cc'd while you tear me a new hole :P Jesse -- jesse mcconnell jesseDOTmcconnellATgmailDOTcom
