Add the Mockito agent properties goal in its own execution

[MBoegers]

• Fixes https://github.com/moderneinc/customer-requests/issues/2968

The problem

The recipe adds -javaagent:${org.mockito:mockito-core:jar} to Surefire's argLine, and needs the maven-dependency-plugin properties goal to define that property. When a project already declared that plugin, the recipe merged <goal>properties</goal> into an execution the project owns:

<execution>
  <id>copy-dependencies</id>
  <phase>package</phase>          <!-- runs after test -->
  <goals>
    <goal>copy-dependencies</goal>
    <goal>properties</goal>       <!-- merged in -->
  </goals>
</execution>

An execution owns the phase and the configuration of every goal it lists, so the merged goal inherited both. Bound to package, properties runs after Surefire forks, the placeholder is passed through verbatim, and the build fails with:

Error opening zip file or JAR manifest missing : ${org.mockito:mockito-core:jar}
[ERROR] Error occurred during initialization of VM

Two further problems came from the same merge:

• The XPath .../executions/execution/goals had no positional predicate and the visitor no one-shot guard, so a plugin with N executions got <goal>properties</goal> appended to all N goal lists.
• PropertiesMojo and AbstractDependencyMojo (the base of copy-dependencies, unpack, analyze, …) both declare a skip parameter. Maven's configuration finalizer matches by parameter name, so an execution carrying <skip> silently skipped the merged goal — the same broken build, with a phase that looks perfectly fine.

The fix

The properties goal now always lands in an execution of its own, never merged into one the project declares:

<execution>
  <id>get-mockito-agent-path</id>
  <goals>
    <goal>properties</goal>
  </goals>
</execution>

No <phase>, so Maven binds each goal of the execution to that goal's own default — initialize for dependency:properties, verified against the mojo descriptor in every published plugin version from 2.4 to 3.11.0.

The explicit <id> is load-bearing rather than cosmetic. Maven merges executions by id — for parent inheritance and for pluginManagement injection alike — and an omitted id is default. Without an id this execution would be captured by any id-less execution declared upstream and handed its <phase>, re-entering the same bug from another direction; and appending an id-less execution next to a project's own id-less one is a duplicate-id model validation error.

The guard is runsPropertiesGoalAtDefaultPhase: we rely on an existing properties goal only when its execution declares no <phase>, because that is the one case where its timing is self-evident. Where a project binds the goal to a phase of its own, deciding whether that lands before the tests would mean reasoning about lifecycle ordering, inheritance and property interpolation, so the goal gets its own execution instead. Worst case that is a second run of a goal which only sets properties; it is never a broken build. The check is mirrored against the document because the resolved model is not refreshed between cycles.

This collapses the four-branch cascade to a single path and retires ChangePluginExecutions and AddOrUpdateChildTag from this recipe. Neither can express the operation: ChangePluginExecutions replaces the whole <executions> element, and AddOrUpdateChildTag is name-keyed and so cannot append a sibling <execution>. Dropping the former also closes a second route to the reported error — it matches groupId with .orElse(null) where AddPluginVisitor defaults the implied Apache group, so a <plugin> declared without a <groupId> used to no-op silently while the argLine was still written.

Tests

Four scenarios added:

• addsSeparateExecutionWhenExistingExecutionRunsAfterTests — the reported reproduction
• addsSeparateExecutionWhenPropertiesGoalIsBoundToAPhase — we do not rely on a phase-bound properties goal
• addsSingleExecutionWhenMavenDependencyPluginHasSeveralExecutions — one execution added regardless of how many exist, with an implied groupId
• plus the existing suite, where twelve expected outputs changed: nine gained the <id> line, three moved the goal out of the project's execution into its own

Notes for review

The three restructured fixtures did not encode broken behaviour. Their executions are phase-less, and Maven binds each goal of a phase-less execution to that goal's own default, so the previous merge was functionally correct there. This change is a correctness fix for the explicit-late-phase case, plus hardening against configuration inheritance and the N-execution amplification.

One pre-existing gap is untouched and worth a separate look: branch selection reads the resolved model, which includes parent-inherited and active-profile plugins, while the edit is anchored at /project/build/plugins of the current document. A plugin declared only in a parent or only in a profile therefore gets the argLine without the properties goal. It is not the failure reported here, and no test covers it today.