I *think* you could use a ${project} parameter, which will return an
instance of org.apache.maven.project.MavenProject (artifactId:
maven-project), and then use something like:
MavenProject.setArtifacts(..) or something (the exact API here escapes
me, but a good IDE should help you). You'll have to use
MavenProject.getArtifacts(), and filter out anything you don't want.
Then, I'd bind the plugin's execution to the process-test-classes phase
of the build, using an <execution/> section in the plugin definition
inside your POM. Then, it's a matter of calling:
mvn test
Though, I do have to ask: why would you want to do this? Also, be warned
that this may affect all plugins executing after your plugin, and in
strange ways.
HTH,
John
Matthew Beermann wrote:
It's my understanding that plugins do not communicate with one another
directly; rather, they utilize their parameters. Which is all well and good, so
here's what I'm trying to do:
I'm writing a plugin that overrides Surefire's classpath to a classpath that I've constructed. In particular, I do _not_ want the project's <dependencies/> to be included on the test classpath. It appears that all I have to do is alter the value of ${project.testClasspathElements}.
So... how do I do that? Maven's @parameter magic annotation lets me get the value in, but how do I write it back back out again?
A related question might be: what's the "lifespan" of changes I make to these properties? In other words, if I run "mvn myplugin test", it appears that the changes I've made have been discarded by the time the surefire plugin sees them.
--Matthew
---------------------------------
Yahoo! Photos – Showcase holiday pictures in hardcover
Photo Books. You design it and we’ll bind it!
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
