From 6772eb3158441a30f1e30d3fbafa8685817e4819 Mon Sep 17 00:00:00 2001 From: Sylwester Lachiewicz Date: Mon, 10 Aug 2026 02:37:41 +0200 Subject: [PATCH 1/2] Rename the FAQ ahead of converting it Git records a rename plus a rewrite in one commit as a delete and an add, which stops 'git log --follow'. Splitting the rename out keeps the history. Please merge or rebase rather than squash. Generated-by: Claude Opus 5 (1M context) --- .../src/site/{fml/faq.fml => markdown/faq.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename maven-plugin-testing-harness/src/site/{fml/faq.fml => markdown/faq.md} (100%) diff --git a/maven-plugin-testing-harness/src/site/fml/faq.fml b/maven-plugin-testing-harness/src/site/markdown/faq.md similarity index 100% rename from maven-plugin-testing-harness/src/site/fml/faq.fml rename to maven-plugin-testing-harness/src/site/markdown/faq.md From 37faa5dd740433694aef88940cb29cb20998802b Mon Sep 17 00:00:00 2001 From: Sylwester Lachiewicz Date: Mon, 10 Aug 2026 02:38:59 +0200 Subject: [PATCH 2/2] Convert the FAQ from FML to Markdown This FAQ exists only on this branch: master was frozen and its FML deleted, so maven-plugin-testing-harness/src/site/fml/faq.fml here is the only source for the published page. doxia-converter cannot target FML usefully - the questions come out as link-reference syntax rather than headings, the [top] back-links become links to a nonexistent 'top' page, and the contents links lose their # anchors. The page is written out by hand instead. Explicit anchors keep the existing deep links working. FML routes every through DoxiaUtils.encodeId, and the rendered anchor is not the question text: both entries here differ from what a heading alone would produce. The published anchors have no trailing .3F because the ids omit the question mark, and the second is What_kinds_of_unit_tests_are_supported - plural - while the question reads "What kind of unit tests are supported?". Neither could have been reproduced by relying on the id Doxia derives from the heading, so both are written out explicitly. They are written as rather than . maven-site-plugin 3.21.0 drops the name attribute from inline HTML anchors while 3.22.0 keeps it; this branch resolves to 3.22.0, so name would have worked here, but id is the primary path in Xhtml5BaseParser, is the correct HTML5 form, and keeps the page safe if it is ever built with an older toolchain. The metadata is the unfenced MultiMarkdown block used by every other markdown page on this branch, and carries only the title, because the FML declared only a title. Adding author or date would have introduced meta elements the published page does not currently have. Verified by building the site before and after and comparing the set of anchors the generated faq.html actually serves. All 4 anchors present before are still present after (7 after, the extra 3 being the ids Doxia derives from the new headings): What_is_a_Mojo_Testing_Harness What_kinds_of_unit_tests_are_supported bodyColumn top The is byte-identical, which also confirms the metadata was parsed rather than rendered into the page. site.xml needs no edit - both source paths render to faq.html. FML generates a [top] back-link after each answer; those are dropped rather than hand-written. The question renders as an h3 heading rather than a definition term. Those are the only rendering losses; the definition list inside the second answer is kept as real
markup. Generated-by: Claude Opus 5 (1M context) --- .../src/site/markdown/faq.md | 122 +++++++++--------- 1 file changed, 58 insertions(+), 64 deletions(-) diff --git a/maven-plugin-testing-harness/src/site/markdown/faq.md b/maven-plugin-testing-harness/src/site/markdown/faq.md index d07aa76..bafc7b2 100644 --- a/maven-plugin-testing-harness/src/site/markdown/faq.md +++ b/maven-plugin-testing-harness/src/site/markdown/faq.md @@ -1,68 +1,62 @@ - +title: Frequently Asked Questions - + + + + + + + + + + + + + + + - http://www.apache.org/licenses/LICENSE-2.0 + -Unless required by applicable law or agreed to in writing, -software distributed under the License is distributed on an -"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY -KIND, either express or implied. See the License for the -specific language governing permissions and limitations -under the License. ---> +# Frequently Asked Questions - - - - What is a Mojo Testing Harness? - -

- A unit test attempts to verify a mojo as an isolated unit, by mocking out the rest of the Maven environment. - A mojo unit test does not attempt to run your plugin in the context of a real Maven build. - Unit tests are designed to be fast. -

-

- This testing library is NOT designed for integration or functional testing: - maven-invoker-plugin is the way to go if you need it, - which gives you a complete Maven environment at the cost of more resources and time consumption. -

- - - - What kind of unit tests are supported? - -

-

-
JUnit 5 Extension - @MojoTest annotation
-
The preferred way to test Mojos is to use the JUnit 5 extension provided by the - maven-plugin-testing-harness. You can annotate your test class with @MojoTest - to have the extension set up the necessary Maven components for you. You can then inject your Mojo - and any required Maven components directly into your test class. - See javadocs for examples. -
-
TestCase from JUnit - deprecated
-
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 - deprecated
-
Mojos are written to take specific advantage of the Plexus container. - If you need Plexus container services, you could write your class which extends PlexusTestCase, - instead of TestCase.
-
TestCase from Testing Harness - deprecated
-
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.
-
-

- - - - +1. [What is a Mojo Testing Harness?](#What_is_a_Mojo_Testing_Harness) +2. [What kind of unit tests are supported?](#What_kinds_of_unit_tests_are_supported) + + + +### What is a Mojo Testing Harness? + +A unit test attempts to verify a mojo as an isolated unit, by mocking out the rest of the Maven environment. +A mojo unit test does not attempt to run your plugin in the context of a real Maven build. +Unit tests are designed to be fast. + +This testing library is **NOT** designed for integration or functional testing: +[`maven-invoker-plugin`](/plugins/maven-invoker-plugin/) is the way to go if you need it, +which gives you a complete Maven environment at the cost of more resources and time consumption. + + + +### What kind of unit tests are supported? + +
+
JUnit 5 Extension - @MojoTest annotation
+
The preferred way to test Mojos is to use the JUnit 5 extension provided by the +maven-plugin-testing-harness. You can annotate your test class with @MojoTest +to have the extension set up the necessary Maven components for you. You can then inject your Mojo +and any required Maven components directly into your test class. +See javadocs for examples.
+
TestCase from JUnit - deprecated
+
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 - deprecated
+
Mojos are written to take specific advantage of the Plexus container. +If you need Plexus container services, you could write your class which extends PlexusTestCase, +instead of TestCase.
+
TestCase from Testing Harness - deprecated
+
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.
+