http://git-wip-us.apache.org/repos/asf/maven-surefire/blob/8970909c/maven-surefire-plugin/src/site/apt/usage.apt.vm ---------------------------------------------------------------------- diff --git a/maven-surefire-plugin/src/site/apt/usage.apt.vm b/maven-surefire-plugin/src/site/apt/usage.apt.vm index f32c5b0..53dc424 100644 --- a/maven-surefire-plugin/src/site/apt/usage.apt.vm +++ b/maven-surefire-plugin/src/site/apt/usage.apt.vm @@ -1,13 +1,13 @@ ------- -Usage ------- -Brett Porter -Allan Ramirez -Stephen Connolly ------- -2011-06-27 ------- - + ------ + Usage + ------ + Brett Porter + Allan Ramirez + Stephen Connolly + ------ + 2011-06-27 + ------ + ~~ Licensed to the Apache Software Foundation (ASF) under one ~~ or more contributor license agreements. See the NOTICE file ~~ distributed with this work for additional information @@ -31,72 +31,67 @@ Stephen Connolly Usage #{if}(${project.artifactId}=="maven-surefire-plugin") -Best practice is to define the version of the Surefire plugin that you want to use in either your << -<pom.xml>>> -or a parent << -<pom.xml>>> + Best practice is to define the version of the Surefire plugin that you want to use in either your <<<pom.xml>>> + or a parent <<<pom.xml>>> +---+ <project> - [...] - <build> - <pluginManagement> - <plugins> - <plugin> - <groupId>${project.groupId}</groupId> - <artifactId>${project.artifactId}</artifactId> - <version>${project.version}</version> - </plugin> - </plugins> - </pluginManagement> - </build> - [...] + [...] + <build> + <pluginManagement> + <plugins> + <plugin> + <groupId>${project.groupId}</groupId> + <artifactId>${project.artifactId}</artifactId> + <version>${project.version}</version> + </plugin> + </plugins> + </pluginManagement> + </build> + [...] </project> +---+ #{else} -To use the ${thisPlugin} Plugin, you need to add the following configuration to -your << -<pom.xml>>> + To use the ${thisPlugin} Plugin, you need to add the following configuration to + your <<<pom.xml>>> +---+ <project> - [...] - <build> - <plugins> - <plugin> - <groupId>${project.groupId}</groupId> - <artifactId>${project.artifactId}</artifactId> - <version>${project.version}</version> - <executions> - <execution> - <goals> - <goal>integration-test</goal> - <goal>verify</goal> - </goals> - </execution> - </executions> - </plugin> - </plugins> - </build> - [...] + [...] + <build> + <plugins> + <plugin> + <groupId>${project.groupId}</groupId> + <artifactId>${project.artifactId}</artifactId> + <version>${project.version}</version> + <executions> + <execution> + <goals> + <goal>integration-test</goal> + <goal>verify</goal> + </goals> + </execution> + </executions> + </plugin> + </plugins> + </build> + [...] </project> +---+ #{end} #{if}(${project.artifactId}=="maven-surefire-plugin") -The ${thisPlugin} Plugin can be invoked by calling the << -<test>>> phase of the -build lifecycle. + The ${thisPlugin} Plugin can be invoked by calling the <<<test>>> phase of the + build lifecycle. +---+ mvn test +---+ #{else} -The ${thisPlugin} Plugin can be invoked by calling the << -<verify>>> phase of the -build lifecycle. + The ${thisPlugin} Plugin can be invoked by calling the <<<verify>>> phase of the + build lifecycle. +---+ mvn verify @@ -105,372 +100,341 @@ mvn verify * Using different testing providers -Tests in your test source directory can be any combination of the following: + Tests in your test source directory can be any combination of the following: -* TestNG + * TestNG -* JUnit (3.8 or 4.x) + * JUnit (3.8 or 4.x) -* POJO + * POJO -Which providers are available is controlled simply by the inclusion of the -appropriate dependencies (ie, junit:junit for JUnit, org.testng:testng 4.7+ -for TestNG). Since this is required to compile the test classes anyway, no -additional configuration is required. + Which providers are available is controlled simply by the inclusion of the + appropriate dependencies (ie, junit:junit for JUnit, org.testng:testng 4.7+ + for TestNG). Since this is required to compile the test classes anyway, no + additional configuration is required. -Note that any normal Surefire integration works identically no matter which -providers are in use - so you can still produce a Cobertura report and a -Surefire results report on your project web site for your TestNG tests, -for example. + Note that any normal Surefire integration works identically no matter which + providers are in use - so you can still produce a Cobertura report and a + Surefire results report on your project web site for your TestNG tests, + for example. -The POJO provider above allows you to write tests that do not depend on -JUnit. They behave in the same way, running all << -<test*>>> methods that are -public in the class, but the API dependency is not required. To perform -assertions, the JDK 1.4 << -<assert>>> keyword can be used. -See {{{./examples/pojo-test.html} using POJO tests}} for more information. + The POJO provider above allows you to write tests that do not depend on + JUnit. They behave in the same way, running all <<<test*>>> methods that are + public in the class, but the API dependency is not required. To perform + assertions, the JDK 1.4 <<<assert>>> keyword can be used. + See {{{./examples/pojo-test.html} using POJO tests}} for more information. -All of the providers support the Surefire Plugin parameter configurations. -However, there are additional options available if you are running TestNG -tests (including if you are using TestNG to execute your JUnit tests, which -occurs by default if both are present in Surefire). + All of the providers support the Surefire Plugin parameter configurations. + However, there are additional options available if you are running TestNG + tests (including if you are using TestNG to execute your JUnit tests, which + occurs by default if both are present in Surefire). -See {{{./examples/testng.html} Using TestNG}} for more information. + See {{{./examples/testng.html} Using TestNG}} for more information. #{if}(${project.artifactId}=="maven-failsafe-plugin") * Using jetty and ${project.artifactId} -You need to bind one of << -<jetty:run>>>, << -<jetty:run-exploded>>> or << -<jetty:run-war>>> -to the << -<pre-integration-test>>> phase with << -<deamon>>> set to true, bind -<< -<failsafe:integration-test>>> to the << -<integration-test>>> phase, bind << -<jetty:stop>>> -to the << -<post-integration-test>>> phase and finally bind << -<failsafe:verify>>> to -the << -<verify>>> phase. Here is an example: + You need to bind one of <<<jetty:run>>>, <<<jetty:run-exploded>>> or <<<jetty:run-war>>> + to the <<<pre-integration-test>>> phase with <<<deamon>>> set to true, bind + <<<failsafe:integration-test>>> to the <<<integration-test>>> phase, bind <<<jetty:stop>>> + to the <<<post-integration-test>>> phase and finally bind <<<failsafe:verify>>> to + the <<<verify>>> phase. Here is an example: +---+ <project> + [...] + <build> [...] - <build> + <plugins> + [...] + <plugin> + <groupId>${project.groupId}</groupId> + <artifactId>${project.artifactId}</artifactId> + <version>${project.version}</version> + <executions> + <execution> + <id>integration-test</id> + <goals> + <goal>integration-test</goal> + </goals> + </execution> + <execution> + <id>verify</id> + <goals> + <goal>verify</goal> + </goals> + </execution> + </executions> + </plugin> + <plugin> + <groupId>org.mortbay.jetty</groupId> + <artifactId>maven-jetty-plugin</artifactId> + <version>6.1.16</version> [...] - <plugins> - [...] - <plugin> - <groupId>${project.groupId}</groupId> - <artifactId>${project.artifactId}</artifactId> - <version>${project.version}</version> - <executions> - <execution> - <id>integration-test</id> - <goals> - <goal>integration-test</goal> - </goals> - </execution> - <execution> - <id>verify</id> - <goals> - <goal>verify</goal> - </goals> - </execution> - </executions> - </plugin> - <plugin> - <groupId>org.mortbay.jetty</groupId> - <artifactId>maven-jetty-plugin</artifactId> - <version>6.1.16</version> - [...] - <configuration> - [...] - <scanIntervalSeconds>10</scanIntervalSeconds> - <stopPort>8005</stopPort> - <stopKey>STOP</stopKey> - <contextPath>/</contextPath> - [...] - </configuration> - [...] - <executions> - [...] - <execution> - <id>start-jetty</id> - <phase>pre-integration-test</phase> - <goals> - <goal>run-exploded</goal> - </goals> - <configuration> - <scanIntervalSeconds>0</scanIntervalSeconds> - <daemon>true</daemon> - </configuration> - </execution> - <execution> - <id>stop-jetty</id> - <phase>post-integration-test</phase> - <goals> - <goal>stop</goal> - </goals> - </execution> - [...] - </executions> - [...] - </plugin> - [...] - </plugins> + <configuration> + [...] + <scanIntervalSeconds>10</scanIntervalSeconds> + <stopPort>8005</stopPort> + <stopKey>STOP</stopKey> + <contextPath>/</contextPath> + [...] + </configuration> [...] - </build> + <executions> + [...] + <execution> + <id>start-jetty</id> + <phase>pre-integration-test</phase> + <goals> + <goal>run-exploded</goal> + </goals> + <configuration> + <scanIntervalSeconds>0</scanIntervalSeconds> + <daemon>true</daemon> + </configuration> + </execution> + <execution> + <id>stop-jetty</id> + <phase>post-integration-test</phase> + <goals> + <goal>stop</goal> + </goals> + </execution> + [...] + </executions> + [...] + </plugin> + [...] + </plugins> [...] + </build> + [...] </project> +---+ -You then invoke maven with a phase of << -<verify>>> or later in order to run -the integration tests. DO NOT directly invoke any of the phases: -<< -<pre-integration-test>>>, << -<integration-test>>>, or << -<post-integration-test>>> as -these are too long to type and they will likely leave a jetty container running. + You then invoke maven with a phase of <<<verify>>> or later in order to run + the integration tests. DO NOT directly invoke any of the phases: + <<<pre-integration-test>>>, <<<integration-test>>>, or <<<post-integration-test>>> as + these are too long to type and they will likely leave a jetty container running. +---+ mvn verify +---+ -Note: during test development, you will likely run a jetty instance in the background. -to help running the integration tests, it can be handy to bind << -<jetty:stop>>> to -the << -<pre-integration-test>>> phase before << -<jetty:run>>> to flush out any -running jetty instance before starting the integration test jetty instance, e.g. + Note: during test development, you will likely run a jetty instance in the background. + to help running the integration tests, it can be handy to bind <<<jetty:stop>>> to + the <<<pre-integration-test>>> phase before <<<jetty:run>>> to flush out any + running jetty instance before starting the integration test jetty instance, e.g. +---+ <project> + [...] + <build> [...] - <build> + <plugins> + [...] + <plugin> + <groupId>org.mortbay.jetty</groupId> + <artifactId>maven-jetty-plugin</artifactId> + <version>6.1.16</version> [...] - <plugins> - [...] - <plugin> - <groupId>org.mortbay.jetty</groupId> - <artifactId>maven-jetty-plugin</artifactId> - <version>6.1.16</version> - [...] - <executions> - [...] - <execution> - <id>start-jetty</id> - <phase>pre-integration-test</phase> - <goals> - <!-- stop any previous instance to free up the port --> - <goal>stop</goal> - <goal>run-exploded</goal> - </goals> - [...] - </execution> - [...] - </executions> - [...] - </plugin> + <executions> + [...] + <execution> + <id>start-jetty</id> + <phase>pre-integration-test</phase> + <goals> + <!-- stop any previous instance to free up the port --> + <goal>stop</goal> + <goal>run-exploded</goal> + </goals> [...] - </plugins> + </execution> + [...] + </executions> [...] - </build> + </plugin> + [...] + </plugins> [...] + </build> + [...] </project> +---+ * Reporting integration test results -The ${thisPlugin} Plugin uses the exact same format as the ${thatPlugin} Plugin, so to generate a report you just add a -second -Surefire Report Plugin report set using the ${thisPlugin} reports directory, e.g. + The ${thisPlugin} Plugin uses the exact same format as the ${thatPlugin} Plugin, so to generate a report you just add a second + Surefire Report Plugin report set using the ${thisPlugin} reports directory, e.g. +---+ <project> - [...] - <reporting> - <plugins> - <plugin> - <groupId>${project.groupId}</groupId> - <artifactId>maven-surefire-report-plugin</artifactId> - <version>${project.version}</version> - <reportSets> - <reportSet> - <id>integration-tests</id> - <reports> - <report>failsafe-report-only</report> - </reports> - </reportSet> - </plugin> - </plugins> - </reporting> - [...] + [...] + <reporting> + <plugins> + <plugin> + <groupId>${project.groupId}</groupId> + <artifactId>maven-surefire-report-plugin</artifactId> + <version>${project.version}</version> + <reportSets> + <reportSet> + <id>integration-tests</id> + <reports> + <report>failsafe-report-only</report> + </reports> + </reportSet> + </plugin> + </plugins> + </reporting> + [...] </project> +---+ * Running integration tests multiple times -If you need to run your integration tests multiple times, just use multiple executions of the << -<integration-test>>> - goal. You will need to specify a different summary file for each execution, and then configure the << - <verify>>> goal - with the multiple summary files in order to fail the build when any one execution has failures, e.g. + If you need to run your integration tests multiple times, just use multiple executions of the <<<integration-test>>> + goal. You will need to specify a different summary file for each execution, and then configure the <<<verify>>> goal + with the multiple summary files in order to fail the build when any one execution has failures, e.g. - +---+ - <project> - [...] - <reporting> - <plugins> - <plugin> - <groupId>${project.groupId}</groupId> - <artifactId>${project.artifactId}</artifactId> - <version>${project.version}</version> - <executions> - <execution> - <id>integration-test-red-bevels</id> - <goals> - <goal>integration-test</goal> - </goals> - <configuration> - <systemPropertyVariables> - <bevels>red</bevels> - </systemPropertyVariables> - <summaryFile>target/failsafe-reports/failsafe-summary-red-bevels.xml</summaryFile> - </configuration> - </execution> - <execution> - <id>integration-test-no-bevels</id> - <goals> - <goal>integration-test</goal> - </goals> - <configuration> - <systemPropertyVariables> - <bevels>none</bevels> - </systemPropertyVariables> - <summaryFile>target/failsafe-reports/failsafe-summary-no-bevels.xml</summaryFile> - </configuration> - </execution> - <execution> - <id>verify</id> - <goals> - <goal>verify</goal> - </goals> - <configuration> - <summaryFiles> - <summaryFile>target/failsafe-reports/failsafe-summary-red-bevels.xml - </summaryFile> - <summaryFile>target/failsafe-reports/failsafe-summary-no-bevels.xml - </summaryFile> - </summaryFiles> - </configuration> - </execution> - </executions> - </plugin> - </plugins> - </reporting> - [...] - </project> - +---+ - - * Using in multi-module projects - - The recommendations for using the ${thisPlugin} Plugin listed at the top of this page are fine for 95% of use - cases. - When you are defining a shared definition of the ${thisPlugin} Plugin in a parent pom, it is considered best - practice - to define an execution id in order to allow child projects to override the configuration. Thus you might have - the - following in your parent << - <pom.xml>>> - - +---+ - <project> - [...] - <build> - <pluginManagement> - <plugins> - <plugin> - <groupId>${project.groupId}</groupId> - <artifactId>${project.artifactId}</artifactId> - <version>${project.version}</version> - <executions> - <execution> - <id>integration-test</id> - <goals> - <goal>integration-test</goal> - <goal>verify</goal> - </goals> - </execution> - </executions> - </plugin> - </plugins> - </pluginManagement> - </build> - [...] - </project> - +---+ - - The child projects can then trigger usage of the ${thisPlugin} Plugin with - - +---+ - <project> - [...] - <build> - <plugins> - <plugin> - <groupId>${project.groupId}</groupId> - <artifactId>${project.artifactId}</artifactId> - <version>${project.version}</version> - </plugin> - </plugins> - </build> - [...] - </project> - +---+ - - For very complex builds, it may be better to separate the executions for the << - <integration-test>>> and << - <verify>>> - goals. - - +---+ - <project> - [...] - <build> - <pluginManagement> - <plugins> - <plugin> - <groupId>${project.groupId}</groupId> - <artifactId>${project.artifactId}</artifactId> - <version>${project.version}</version> - <executions> - <execution> - <id>integration-test</id> - <goals> - <goal>integration-test</goal> - </goals> - </execution> - <execution> - <id>verify</id> - <goals> - <goal>verify</goal> - </goals> - </execution> - </executions> - </plugin> - </plugins> - </pluginManagement> - </build> - [...] - </project> - +---+ ++---+ +<project> + [...] + <reporting> + <plugins> + <plugin> + <groupId>${project.groupId}</groupId> + <artifactId>${project.artifactId}</artifactId> + <version>${project.version}</version> + <executions> + <execution> + <id>integration-test-red-bevels</id> + <goals> + <goal>integration-test</goal> + </goals> + <configuration> + <systemPropertyVariables> + <bevels>red</bevels> + </systemPropertyVariables> + <summaryFile>target/failsafe-reports/failsafe-summary-red-bevels.xml</summaryFile> + </configuration> + </execution> + <execution> + <id>integration-test-no-bevels</id> + <goals> + <goal>integration-test</goal> + </goals> + <configuration> + <systemPropertyVariables> + <bevels>none</bevels> + </systemPropertyVariables> + <summaryFile>target/failsafe-reports/failsafe-summary-no-bevels.xml</summaryFile> + </configuration> + </execution> + <execution> + <id>verify</id> + <goals> + <goal>verify</goal> + </goals> + <configuration> + <summaryFiles> + <summaryFile>target/failsafe-reports/failsafe-summary-red-bevels.xml</summaryFile> + <summaryFile>target/failsafe-reports/failsafe-summary-no-bevels.xml</summaryFile> + </summaryFiles> + </configuration> + </execution> + </executions> + </plugin> + </plugins> + </reporting> + [...] +</project> ++---+ + +* Using in multi-module projects + + The recommendations for using the ${thisPlugin} Plugin listed at the top of this page are fine for 95% of use cases. + When you are defining a shared definition of the ${thisPlugin} Plugin in a parent pom, it is considered best practice + to define an execution id in order to allow child projects to override the configuration. Thus you might have the + following in your parent <<<pom.xml>>> + ++---+ +<project> + [...] + <build> + <pluginManagement> + <plugins> + <plugin> + <groupId>${project.groupId}</groupId> + <artifactId>${project.artifactId}</artifactId> + <version>${project.version}</version> + <executions> + <execution> + <id>integration-test</id> + <goals> + <goal>integration-test</goal> + <goal>verify</goal> + </goals> + </execution> + </executions> + </plugin> + </plugins> + </pluginManagement> + </build> + [...] +</project> ++---+ + + The child projects can then trigger usage of the ${thisPlugin} Plugin with + ++---+ +<project> + [...] + <build> + <plugins> + <plugin> + <groupId>${project.groupId}</groupId> + <artifactId>${project.artifactId}</artifactId> + <version>${project.version}</version> + </plugin> + </plugins> + </build> + [...] +</project> ++---+ + + For very complex builds, it may be better to separate the executions for the <<<integration-test>>> and <<<verify>>> + goals. + ++---+ +<project> + [...] + <build> + <pluginManagement> + <plugins> + <plugin> + <groupId>${project.groupId}</groupId> + <artifactId>${project.artifactId}</artifactId> + <version>${project.version}</version> + <executions> + <execution> + <id>integration-test</id> + <goals> + <goal>integration-test</goal> + </goals> + </execution> + <execution> + <id>verify</id> + <goals> + <goal>verify</goal> + </goals> + </execution> + </executions> + </plugin> + </plugins> + </pluginManagement> + </build> + [...] +</project> ++---+ #{end} \ No newline at end of file
http://git-wip-us.apache.org/repos/asf/maven-surefire/blob/8970909c/maven-surefire-report-plugin/src/site/apt/examples/changing-report-name.apt.vm ---------------------------------------------------------------------- diff --git a/maven-surefire-report-plugin/src/site/apt/examples/changing-report-name.apt.vm b/maven-surefire-report-plugin/src/site/apt/examples/changing-report-name.apt.vm index 15cc561..61da62f 100644 --- a/maven-surefire-report-plugin/src/site/apt/examples/changing-report-name.apt.vm +++ b/maven-surefire-report-plugin/src/site/apt/examples/changing-report-name.apt.vm @@ -1,10 +1,10 @@ ------- -Changing Report Name ------- -Allan Ramirez ------- -July 2006 ------- + ------ + Changing Report Name + ------ + Allan Ramirez + ------ + July 2006 + ------ ~~ Copyright 2006 The Apache Software Foundation. ~~ @@ -25,31 +25,28 @@ July 2006 Changing Report Name -In order to configure the file name of the generated report (which is -<"surefire-report"> by default), the < -<outputName>> property should - be set to its new name. + In order to configure the file name of the generated report (which is + <"surefire-report"> by default), the <<outputName>> property should + be set to its new name. - +----+ - <project> - [...] - <reporting> - <plugins> - <plugin> - <groupId>org.apache.maven.plugins</groupId> - <artifactId>maven-surefire-report-plugin</artifactId> - <version>${project.version}</version> - <configuration> - <outputName>newname</outputName> - </configuration> - </plugin> - </plugins> - </reporting> - [...] - </project> - +----+ ++----+ +<project> + [...] + <reporting> + <plugins> + <plugin> + <groupId>org.apache.maven.plugins</groupId> + <artifactId>maven-surefire-report-plugin</artifactId> + <version>${project.version}</version> + <configuration> + <outputName>newname</outputName> + </configuration> + </plugin> + </plugins> + </reporting> + [...] +</project> ++----+ - And after executing the << - <mvn site>>>, the generated report file is named - to < - <newname.html>>. + And after executing the <<<mvn site>>>, the generated report file is named + to <<newname.html>>. http://git-wip-us.apache.org/repos/asf/maven-surefire/blob/8970909c/maven-surefire-report-plugin/src/site/apt/examples/cross-referencing.apt.vm ---------------------------------------------------------------------- diff --git a/maven-surefire-report-plugin/src/site/apt/examples/cross-referencing.apt.vm b/maven-surefire-report-plugin/src/site/apt/examples/cross-referencing.apt.vm index e87600f..0714e61 100644 --- a/maven-surefire-report-plugin/src/site/apt/examples/cross-referencing.apt.vm +++ b/maven-surefire-report-plugin/src/site/apt/examples/cross-referencing.apt.vm @@ -1,10 +1,10 @@ ------- -Source Code Cross Reference ------- -Allan Ramirez ------- -July 2006 ------- + ------ + Source Code Cross Reference + ------ + Allan Ramirez + ------ + July 2006 + ------ ~~ Copyright 2006 The Apache Software Foundation. ~~ @@ -25,65 +25,54 @@ July 2006 Source Code Cross Reference -There are times when we need to know right away the line number of the -source code that caused the failure of the test. The Surefire Report Plugin -has the capability to cross reference the source code that made the test -failed. To be able to activate it, the << -<maven-jxr-plugin>>> should - also be declared in the \ - <reporting - \> section of the POM along with the - << - <maven-surefire-report-plugin>>>. For more details, please read the - documentation of the - {{{http://maven.apache.org/plugins/maven-jxr-plugin/}Maven JXR Plugin}}. + There are times when we need to know right away the line number of the + source code that caused the failure of the test. The Surefire Report Plugin + has the capability to cross reference the source code that made the test + failed. To be able to activate it, the <<<maven-jxr-plugin>>> should + also be declared in the \<reporting\> section of the POM along with the + <<<maven-surefire-report-plugin>>>. For more details, please read the + documentation of the + {{{http://maven.apache.org/plugins/maven-jxr-plugin/}Maven JXR Plugin}}. - +----+ - <project> - [...] - <reporting> - <plugins> - <plugin> - <groupId>org.apache.maven.plugins</groupId> - <artifactId>maven-surefire-report-plugin</artifactId> - <version>${project.version}</version> - <configuration> - <!-- place your configuration here --> - </configuration> - </plugin> - <plugin> - <groupId>org.apache.maven.plugins</groupId> - <artifactId>maven-jxr-plugin</artifactId> - <version>2.1</version> - </plugin> - </plugins> - </reporting> - [...] - </project> - +----+ ++----+ +<project> + [...] + <reporting> + <plugins> + <plugin> + <groupId>org.apache.maven.plugins</groupId> + <artifactId>maven-surefire-report-plugin</artifactId> + <version>${project.version}</version> + <configuration> + <!-- place your configuration here --> + </configuration> + </plugin> + <plugin> + <groupId>org.apache.maven.plugins</groupId> + <artifactId>maven-jxr-plugin</artifactId> + <version>2.1</version> + </plugin> + </plugins> + </reporting> + [...] +</project> ++----+ - After executing << - <mvn site>>> for site generation, You'll notice that from - the < - <Failure Details>> section of the report, the link is available to - redirect you to the source code that caused the failure. + After executing <<<mvn site>>> for site generation, You'll notice that from + the <<Failure Details>> section of the report, the link is available to + redirect you to the source code that caused the failure. - From the figure below the code that caused the failure is - <com.test.proj.AppTest:36> + From the figure below the code that caused the failure is + <com.test.proj.AppTest:36> - [../images/failure-details.PNG] Failure Details +[../images/failure-details.PNG] Failure Details - The link will redirect you to the source by clicking it. + The link will redirect you to the source by clicking it. - [../images/xref.PNG] The source +[../images/xref.PNG] The source - * Disable the Cross Reference Link +* Disable the Cross Reference Link - To disable the link to the source code, the < - <linkXRef>> property should - be set to < - <false>>. Or another way is by not declaring the - << - <maven-jxr-plugin>>> to the \ - <reporting - \> section. + To disable the link to the source code, the <<linkXRef>> property should + be set to <<false>>. Or another way is by not declaring the + <<<maven-jxr-plugin>>> to the \<reporting\> section. http://git-wip-us.apache.org/repos/asf/maven-surefire/blob/8970909c/maven-surefire-report-plugin/src/site/apt/examples/report-custom-location.apt.vm ---------------------------------------------------------------------- diff --git a/maven-surefire-report-plugin/src/site/apt/examples/report-custom-location.apt.vm b/maven-surefire-report-plugin/src/site/apt/examples/report-custom-location.apt.vm index de5babc..ccebf0c 100644 --- a/maven-surefire-report-plugin/src/site/apt/examples/report-custom-location.apt.vm +++ b/maven-surefire-report-plugin/src/site/apt/examples/report-custom-location.apt.vm @@ -1,10 +1,10 @@ ------- -Custom Location of the Surefire Report ------- -Allan Ramirez ------- -July 2006 ------- + ------ + Custom Location of the Surefire Report + ------ + Allan Ramirez + ------ + July 2006 + ------ ~~ Copyright 2006 The Apache Software Foundation. ~~ @@ -25,53 +25,48 @@ July 2006 Configuring the Output Location as part of the Project Reports -To change the location of the generated output report along with other -project reports. The < -<outputDirectory>> property of both - << - <maven-site-plugin>>> and << - <maven-surefire-report-plugin>>> should be set to the - new path. For more information, see the documentation of the - {{{http://maven.apache.org/plugins/maven-site-plugin/}Maven Site Plugin}}. + To change the location of the generated output report along with other + project reports. The <<outputDirectory>> property of both + <<<maven-site-plugin>>> and <<<maven-surefire-report-plugin>>> should be set to the + new path. For more information, see the documentation of the + {{{http://maven.apache.org/plugins/maven-site-plugin/}Maven Site Plugin}}. - +----+ - <project> - [...] - <reporting> - <plugins> - <plugin> - <groupId>org.apache.maven.plugins</groupId> - <artifactId>maven-surefire-report-plugin</artifactId> - <version>${project.version}</version> - <configuration> - <outputDirectory>${basedir}/target/newsite</outputDirectory> - </configuration> - </plugin> - <plugin> - <groupId>org.apache.maven.plugins</groupId> - <artifactId>maven-site-plugin</artifactId> - <version>2.1</version> - <configuration> - <outputDirectory>${basedir}/target/newsite</outputDirectory> - </configuration> - </plugin> - </plugins> - </reporting> - [...] - </project> - +----+ ++----+ +<project> + [...] + <reporting> + <plugins> + <plugin> + <groupId>org.apache.maven.plugins</groupId> + <artifactId>maven-surefire-report-plugin</artifactId> + <version>${project.version}</version> + <configuration> + <outputDirectory>${basedir}/target/newsite</outputDirectory> + </configuration> + </plugin> + <plugin> + <groupId>org.apache.maven.plugins</groupId> + <artifactId>maven-site-plugin</artifactId> + <version>2.1</version> + <configuration> + <outputDirectory>${basedir}/target/newsite</outputDirectory> + </configuration> + </plugin> + </plugins> + </reporting> + [...] +</project> ++----+ - Please take note that if the < - <outputDirectory>> of the Site Plugin - is not configured, the output location of the Surefire report will still - be the default. + Please take note that if the <<outputDirectory>> of the Site Plugin + is not configured, the output location of the Surefire report will still + be the default. - * Configuring the Output Location using Standalone Goal +* Configuring the Output Location using Standalone Goal - To change the location of the generated output report using the standalone - goal, the < - <outputDirectory>> property should be set to the new path. + To change the location of the generated output report using the standalone + goal, the <<outputDirectory>> property should be set to the new path. - +---+ - mvn surefire-report:report -DoutputDirectory=newpath - +---+ ++---+ +mvn surefire-report:report -DoutputDirectory=newpath ++---+ http://git-wip-us.apache.org/repos/asf/maven-surefire/blob/8970909c/maven-surefire-report-plugin/src/site/apt/examples/show-failures.apt.vm ---------------------------------------------------------------------- diff --git a/maven-surefire-report-plugin/src/site/apt/examples/show-failures.apt.vm b/maven-surefire-report-plugin/src/site/apt/examples/show-failures.apt.vm index 0fdcd52..7ee1edd 100644 --- a/maven-surefire-report-plugin/src/site/apt/examples/show-failures.apt.vm +++ b/maven-surefire-report-plugin/src/site/apt/examples/show-failures.apt.vm @@ -1,10 +1,10 @@ ------- -Showing Failure Tests ------- -Allan Ramirez ------- -July 2006 ------- + ------ + Showing Failure Tests + ------ + Allan Ramirez + ------ + July 2006 + ------ ~~ Copyright 2006 The Apache Software Foundation. ~~ @@ -25,36 +25,33 @@ July 2006 Showing Failure Tests -By default, the Surefire Report Plugin shows all test result status (success -and failures) in the generated HTML. To be able to show the failures only, the -property < -<showSuccess>> should be set to < - <false>>. - - +----+ - <project> - [...] - <reporting> - <plugins> - <plugin> - <groupId>org.apache.maven.plugins</groupId> - <artifactId>maven-surefire-report-plugin</artifactId> - <version>${project.version}</version> - <configuration> - <showSuccess>false</showSuccess> - </configuration> - </plugin> - </plugins> - </reporting> - [...] - </project> - +----+ - - Then execute << - <mvn site>>> for the report generation. - - It can also be set via commandline with the standalone goal. - - +----+ - mvn surefire-report:report -DshowSuccess=false - +----+ + By default, the Surefire Report Plugin shows all test result status (success + and failures) in the generated HTML. To be able to show the failures only, the + property <<showSuccess>> should be set to <<false>>. + ++----+ +<project> + [...] + <reporting> + <plugins> + <plugin> + <groupId>org.apache.maven.plugins</groupId> + <artifactId>maven-surefire-report-plugin</artifactId> + <version>${project.version}</version> + <configuration> + <showSuccess>false</showSuccess> + </configuration> + </plugin> + </plugins> + </reporting> + [...] +</project> ++----+ + + Then execute <<<mvn site>>> for the report generation. + + It can also be set via commandline with the standalone goal. + ++----+ + mvn surefire-report:report -DshowSuccess=false ++----+ http://git-wip-us.apache.org/repos/asf/maven-surefire/blob/8970909c/maven-surefire-report-plugin/src/site/apt/usage.apt.vm ---------------------------------------------------------------------- diff --git a/maven-surefire-report-plugin/src/site/apt/usage.apt.vm b/maven-surefire-report-plugin/src/site/apt/usage.apt.vm index 62ba366..ef71d13 100644 --- a/maven-surefire-report-plugin/src/site/apt/usage.apt.vm +++ b/maven-surefire-report-plugin/src/site/apt/usage.apt.vm @@ -1,10 +1,10 @@ ------- -Usage ------- -Allan Ramirez ------- -July 2006 ------- + ------ + Usage + ------ + Allan Ramirez + ------ + July 2006 + ------ ~~ Copyright 2006 The Apache Software Foundation. ~~ @@ -27,41 +27,39 @@ Usage * Generate the report as part of Project Reports -To generate the Surefire report as part of the site generation, add the following in -the \ -<reporting\> section of your POM: + To generate the Surefire report as part of the site generation, add the following in + the \<reporting\> section of your POM: +---+ <project> - ... - <reporting> - <plugins> - <plugin> - <groupId>org.apache.maven.plugins</groupId> - <artifactId>maven-surefire-report-plugin</artifactId> - <version>${project.version}</version> - </plugin> - </plugins> - </reporting> - ... + ... + <reporting> + <plugins> + <plugin> + <groupId>org.apache.maven.plugins</groupId> + <artifactId>maven-surefire-report-plugin</artifactId> + <version>${project.version}</version> + </plugin> + </plugins> + </reporting> + ... </project> +---+ -When the << -<mvn site>>> is invoked, the report will be automatically - included in the Project Reports menu as shown in the figure below. + When the <<<mvn site>>> is invoked, the report will be automatically + included in the Project Reports menu as shown in the figure below. - [images/surefire-sample1.PNG] Sample Surefire Report +[images/surefire-sample1.PNG] Sample Surefire Report - * Generate the report as standalone +* Generate the report as standalone - The Surefire report can also generate the report using its standalone goal: + The Surefire report can also generate the report using its standalone goal: - +---+ - mvn surefire-report:report - +---+ ++---+ +mvn surefire-report:report ++---+ - A HTML report should be generated in <<<$\{basedir\}/target/site/surefire-report.html>>>. + A HTML report should be generated in <<<$\{basedir\}/target/site/surefire-report.html>>>. - [images/surefire-sample2.PNG] Sample standalone surefire-report +[images/surefire-sample2.PNG] Sample standalone surefire-report
