There are two things you need to test, right? 1. unit test functionality within the plugin, to make sure that subcomponents and classes within the implementation are functioning correctly
2. integration test functionality that depends on Maven (the runtime context) to produce results. This is what most of these tests currently do, in one way or other. I agree that we need to have a formalized integration-testing phase where the plugin can run in its container (maven), and output can be verified. This will involve allowing Maven to read the plugin from somewhere, which means it has to be packaged and installed somewhere...without polluting the main local repository. When I ran the tests after working on a couple of jiras, they would not pass without me first running 'mvn - Dmaven.test.skip=true install' and then trying...this to me means that it's polluting the local repository with an untested plugin. If you really think you can ensure that the local repository isn't polluted, and can make the build complete with tests executed in a single pass, then it should be pretty easy to revert the tests back to use the embedder or whatever...simply change the method in the abstract test case that actually runs the maven build, and that will get you very close. Aside from that discussion, it's also possible to run the integration tests using the real version of the plugin, though that seems much more fragile to me. In this case, you'd be reliant on the metadata to be installed in the testing local repository and take precedence over the metadata in the remote repository. Then, there is no separate testing-only plugin version to be concerned with. What those issues say to me is that there's some place where an integration test is running the deploy step...and that the staging process for the plugin needs to remove the distributionManagement section, or otherwise nullify it so deployment is not possible. That's an easy fix in the maven-plugin-testing-tools. -john On 12/20/06, Fabrizio Giustina <[EMAIL PROTECTED]> wrote:
On 12/20/06, Kenney Westerhof <[EMAIL PROTECTED]> wrote: > There was support in maven to run plugins from target/, but it was broken: > MNG-2677 (originally MNG-870). well, the eclipse plugin was using that till a few weeks ago and I can assure it was working! I was able to modify the plugin code from eclipse, to set breakpoints and to run junit tests from the IDE without having to rerun maven at all (it was only needed when adding new parameters, since the plugin descriptor had to be generated by maven). As said, the only problem was the inability to run reactor builds: for that reason the only test that was needing it was implemented using a command line call and never enabled in the surefire configuration (only run manually). I could be wrong, but if you try to get a revision before John's refactoring it should work this way. I see that the tests didn't do anything special: https://svn.apache.org/viewvc/maven/plugins/tags/maven-eclipse-plugin-2.2/src/test/java/org/apache/maven/plugin/eclipse/AbstractEclipsePluginTestCase.java?revision=393014&view=markup > But would indeed be best if plugin integration tests are done in the integration-test > phase, using the packaged plugin from target/ (which is available from the reactor). well, I'd love to see plugin tests working without having to package a plugin at all. It's a lot better if you are also able to run tests from an IDE. I was pretty happy on how tests were done previously apart from the multiproject stuff and a better control over the test repository... fabrizio --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
