diff --git a/maven-plugin-testing-harness/src/site/apt/examples/artifact.apt b/maven-plugin-testing-harness/src/site/apt/examples/artifact.apt index 1ab5d18..c5aa970 100644 --- a/maven-plugin-testing-harness/src/site/apt/examples/artifact.apt +++ b/maven-plugin-testing-harness/src/site/apt/examples/artifact.apt @@ -106,7 +106,8 @@ public class MyArtifactStub * @param version * @param packaging */ - public ProjectInfoPluginArtifactStub( String groupId, String artifactId, String version, String packaging ) + public ProjectInfoPluginArtifactStub( String groupId, String artifactId, + String version, String packaging ) { this.groupId = groupId; this.artifactId = artifactId; @@ -204,7 +205,8 @@ public class MyProjectStub { ... - Artifact artifact = new MyArtifactStub( getGroupId(), getArtifactId(), getVersion(), getPackaging() ); + Artifact artifact = new MyArtifactStub( getGroupId(), getArtifactId(), + getVersion(), getPackaging() ); artifact.setArtifactHandler( new MyArtifactHandlerStub() ); setArtifact( artifact ); diff --git a/maven-plugin-testing-harness/src/site/apt/examples/complex-mojo-parameters.apt b/maven-plugin-testing-harness/src/site/apt/examples/complex-mojo-parameters.apt index cbc2816..7a9caf9 100644 --- a/maven-plugin-testing-harness/src/site/apt/examples/complex-mojo-parameters.apt +++ b/maven-plugin-testing-harness/src/site/apt/examples/complex-mojo-parameters.apt @@ -25,9 +25,9 @@ Testing Complex Mojo Parameters - <>: This example improves the {{{../getting-started/index.html}cookbook}} for complex Mojo parameters testing. + <>: This example improves the {{{../getting-started/index.html}cookbook}} for testing complex Mojo parameters. - In a real plugin development, you will use specific Maven objects like <<>>, <<>> or + In real plugin development, you will use specific Maven objects like <<>>, <<>> or <<>>. You could use them by defining stubs. Suppose that you have the following dependencies in the maven-my-plugin pom: @@ -90,7 +90,7 @@ public class MyMojo * Create Stubs - You need to create stubs objects to run <<>>. By convention, the package name should + You need to create stub objects to run <<>>. By convention, the package name should reflect the stubs, i.e. in our case <<>>. ----- @@ -159,7 +159,7 @@ public class SettingsStub } ----- -* Configuring <<>> pom +* Configure <<>> pom ----- @@ -169,11 +169,11 @@ public class SettingsStub maven-my-plugin - + target/test-harness/project-to-test - + ${localRepository} diff --git a/maven-plugin-testing-harness/src/site/apt/examples/multiproject.apt b/maven-plugin-testing-harness/src/site/apt/examples/multiproject.apt index 541ada0..1564723 100644 --- a/maven-plugin-testing-harness/src/site/apt/examples/multiproject.apt +++ b/maven-plugin-testing-harness/src/site/apt/examples/multiproject.apt @@ -41,7 +41,7 @@ public class MyMojo } ------ - To test a Mojo in a multiproject area, you need to define several stubs, i.e. for the main test project and his modules. + To test a Mojo in a multiproject area, you need to define several stubs, i.e. for the main test project and its modules. * Create Stubs @@ -99,7 +99,7 @@ public class SubProject2Stub } ----- -* Configuring <<>> pom +* Configure <<>> pom ----- diff --git a/maven-plugin-testing-harness/src/site/apt/examples/repositories.apt b/maven-plugin-testing-harness/src/site/apt/examples/repositories.apt index e95e261..ff4fca1 100644 --- a/maven-plugin-testing-harness/src/site/apt/examples/repositories.apt +++ b/maven-plugin-testing-harness/src/site/apt/examples/repositories.apt @@ -25,10 +25,10 @@ Testing Using Repositories - <>: This example improves the {{{../getting-started/index.html}cookbook}} for repositories testing. + <>: This example improves the {{{../getting-started/index.html}cookbook}} for testing repositories. - Developing Maven plugin needs often to have to play with repositories. Suppose that the MyMojo needs - to download artifacts in your local repository, i.e.: + When developing a Maven plugin you often need to play with repositories. Suppose that the MyMojo needs + to download artifacts into your local repository, i.e.: ----- public class MyMojo @@ -108,7 +108,7 @@ public class MyProjectStub } ----- -* Configuring <<>> pom +* Configure <<>> pom ----- @@ -118,11 +118,11 @@ public class MyProjectStub maven-my-plugin - + ${basedir}/target/test-harness/project-to-test - + ${localRepository} diff --git a/maven-plugin-testing-harness/src/site/apt/getting-started/index.apt b/maven-plugin-testing-harness/src/site/apt/getting-started/index.apt index 000f4ad..985e7ee 100644 --- a/maven-plugin-testing-harness/src/site/apt/getting-started/index.apt +++ b/maven-plugin-testing-harness/src/site/apt/getting-started/index.apt @@ -30,7 +30,7 @@ Cookbook: How To Use Maven Plugin Testing Harness? * Prerequisites - We suppose that you had already created a plugin. In this cookbook, we make reference on <<>> from + We assume that you have already created a plugin. In this cookbook, we make reference to <<>> in <<>> which is generated by the Maven Archetype Plugin, i.e.: ----- @@ -58,9 +58,9 @@ maven-my-plugin * Recipe -** Added <<>> dependency +** Add <<>> dependency - As usually, just add <<>> as following in your pom. Be sure to specify <<>> scope. + As usual, just add <<>> as following in your pom. Be sure to specify <<>> scope. ----- @@ -80,7 +80,7 @@ maven-my-plugin ** Create a <<>> Create a <<>> (by convention) class in <<>> directory. - This class should extends <<>> from <<>>. + This class should extend <<>> from <<>>. ----- public class MyMojoTest @@ -131,7 +131,7 @@ public class MyMojoTest ** Configuring <<>> pom - Just create a pom as usual. The names for groupId and artifactId don't really care since this project will not be deployed. + Just create a pom as usual. The names for groupId and artifactId don't really matter since this project will not be deployed. ----- What kind of unit tests are supported?

-

+
TestCase from JUnit
You could use the JUnit framework to test your plugin in the same way you'd write any other JUnit test cases, i.e. by writing a test class which extends TestCase.
TestCase from Plexus
Mojos are written to take specific advantage of the Plexus - container. If you need Plexus container services, you could write your class wich extends PlexusTestCase, + container. If you need Plexus container services, you could write your class which extends PlexusTestCase, instead of TestCase.
TestCase from Testing Harness
If you need to inject Maven objects into your mojo, you could use the maven-plugin-testing-harness. The maven-plugin-testing-harness is explicitly intended to test the - org.apache.maven.reporting.AbstractMavenReport#execute() implementation.
+ org.apache.maven.reporting.AbstractMavenReport#execute() implementation.

diff --git a/maven-plugin-testing-harness/src/site/site.xml b/maven-plugin-testing-harness/src/site/site.xml index 838dd85..37d8270 100644 --- a/maven-plugin-testing-harness/src/site/site.xml +++ b/maven-plugin-testing-harness/src/site/site.xml @@ -23,7 +23,7 @@ - +