Attach Mockito as an agent

[bboyleonp666]

Type of change

• Enhancement / new feature

Description

This PR is to close #12749. As the future JDK no longer supports the self-attaching agent. To deal with this warning and support future upgrade, this PR explicitly declares mockito-core as a java agent on a module-by-module basis.

Checklist

Please go through this checklist and make sure all applicable tasks have been done

• Make sure all tests pass

[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary for Strimzi - Apache Kafka on Kubernetes and OpenShift 1.1.0-SNAPSHOT:
[INFO]
[INFO] Strimzi - Apache Kafka on Kubernetes and OpenShift . SUCCESS [  0.698 s]
[INFO] Kafka HTTP Agent ................................... SUCCESS [  1.822 s]
[INFO] Tracing Agent ...................................... SUCCESS [  0.046 s]
[INFO] Strimzi test utilities ............................. SUCCESS [  0.035 s]
[INFO] Strimzi CRD annotations ............................ SUCCESS [  0.368 s]
[INFO] Strimzi CRD generator .............................. SUCCESS [  0.904 s]
[INFO] Strimzi API ........................................ SUCCESS [  2.948 s]
[INFO] Kubernetes Mock .................................... SUCCESS [  5.184 s]
[INFO] Kafka Configuration Model .......................... SUCCESS [  0.381 s]
[INFO] Kafka Configuration Model generator ................ SUCCESS [  4.820 s]
[INFO] Strimzi Certificates Manager ....................... SUCCESS [  0.570 s]
[INFO] Strimzi operators common logic ..................... SUCCESS [  5.374 s]
[INFO] Strimzi Topic Operator ............................. SUCCESS [  7.760 s]
[INFO] Strimzi Cluster Operator ........................... SUCCESS [06:51 min]
[INFO] Strimzi User Operator .............................. SUCCESS [ 23.662 s]
[INFO] Kafka Init Container application ................... SUCCESS [  1.258 s]
[INFO] Strimzi system tests ............................... SUCCESS [  0.271 s]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  07:47 min
[INFO] Finished at: 2026-06-02T20:28:30+08:00
[INFO] ------------------------------------------------------------------------

Disclosure

I am using Claude Code to help me dig into the code as well as generating tables to answer questions. However, the ideas and the descriptions are all typed by me manually.

[snyk-io]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues
✅	Licenses	0	0	0	0	0 issues
✅	Code Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

[scholzj]

Thanks for the PR. Can you please explain why does it need to be done on a module by module basis? And why only in some of the modules?

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 75.06%. Comparing base (da5bdfe) to head (d6867b2).
⚠️ Report is 26 commits behind head on main.

Additional details and impacted files

@@             Coverage Diff              @@
##               main   #12788      +/-   ##
============================================
- Coverage     75.16%   75.06%   -0.10%     
+ Complexity     6460     6433      -27     
============================================
  Files           346      346              
  Lines         24336    24279      -57     
  Branches       3123     3111      -12     
============================================
- Hits          18292    18225      -67     
- Misses         4809     4824      +15     
+ Partials       1235     1230       -5     

see 9 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[bboyleonp666]

As illustrated in Mockito's documentation

Starting from Java 21, the JDK restricts the ability of libraries to attach a Java agent to their own JVM.

As a result, we have to explicitly set up the mockito-core as a Java agent.
The reason to apply it on a module by module basis is inspired by #12749 (comment)

So maybe we need to apply it on module-by-module basis.

I tried to do it in root pom.xml as suggested in Mockito's documentation.

<plugin>
     <groupId>org.apache.maven.plugins</groupId>
     <artifactId>maven-dependency-plugin</artifactId>
     <executions>
         <execution>
             <goals>
                 <goal>properties</goal>
             </goals>
         </execution>
     </executions>
 </plugin>
 <plugin>
     <groupId>org.apache.maven.plugins</groupId>
     <artifactId>maven-surefire-plugin</artifactId>
     <configuration>
         <argLine>@{argLine} -javaagent:${org.mockito:mockito-core:jar}</argLine>
     </configuration>
 </plugin>

However, when Maven is doing variable Interpolate, the ${org.mockito:mockito-core:jar} becomes empty since the dependency declaration is nested under the modules. That causes a warning in building stage, which is not allowed due to <failOnWarning>true</failOnWarning>.

strimzi-kafka-operator/pom.xml

Lines 1017 to 1025 in 79fb916

	<execution>
	<id>analyze</id>
	<goals>
	<goal>analyze-only</goal>
	</goals>
	<configuration>
	<failOnWarning>true</failOnWarning>
	</configuration>
	</execution>

So the modules with the mockito-core as dependency (modules that are really using mockito) should all be updated. That way the ${org.mockito:mockito-core:jar} can be parsed correctly.

strimzi-kafka-operator/kafka-init/pom.xml

Lines 75 to 78 in 79fb916

	<dependency>
	<groupId>org.mockito</groupId>
	<artifactId>mockito-core</artifactId>
	</dependency>

Of course we keep the Mockito config globally. However, the will introduce more file changes due to dependency injection, which i think it's not that necessary.

[scholzj]

@bboyleonp666 Ok, I guess having the agent part onlyin some modules makes sense.

But why did you removed the maven-surefire-plugin plugin from the coverage profile?

[bboyleonp666]

Thanks for the question. Let me explain the original motivation and what I found after re-analyzing.

First, it helps to split the modules by whether they have a module-level surefire <argLine> override:

With module-level <argLine>	Without module-level <argLine> (Affected)
cluster-operator	api
kafka-agent	certificate-manager
kafka-init	config-model
operator-common	config-model-generator
topic-operator	crd-annotations
user-operator	crd-generator
	mockkube
	test
	tracing-agent

I was trying everything in a bundle, which misleads myself to think dropping the maven-surefire-plugin in pom.xml is necessary. That was because I found the affected modules (right column) not generating coverage reports after running:

# e.g. for certificate-manager — any module in the right column above
mvn test jacoco:report -Pcoverage -pl certificate-manager -Dmaven.javadoc.skip=true -DfailIfNoTests=false

Which works right after removing it from pom.xml. I didn't notice that it was a completely separate issue until digging deeper.

The root cause is how Maven resolves <argLine> in the coverage profile. ${surefireArgLine} is resolved at POM parse time — before JaCoCo's prepare-agent runs — so Surefire receives an empty string, overriding its normal auto-pickup behavior and detaching the JaCoCo agent entirely. When the block is removed instead, Surefire falls back to auto-pickup of the argLine property JaCoCo sets at runtime, which is the same value @{argLine} would late-bind to. So removing the block (As commit c509b12 does) and using @{argLine} (Scenario A) are functionally equivalent for the affected modules. The modules with a module-level <argLine> are unaffected regardless of scenario, since module-level surefire config always takes precedence over the root profile.

Experiments

I ran experiments across 3 scenarios on 2 representative modules:

• certificate-manager — representing no module-level <argLine>
• operator-common — representing module-level <argLine>@{argLine} -javaagent:mockito</argLine>

The scenarios differ in what pom.xml:1127 (coverage profile surefire block) contains:

Scenario	pom.xml:1127	JaCoCo agent attached
A	<argLine>@{argLine}</argLine>	✅ — @{argLine} late-binds to what prepare-agent set 1
B	<argLine>${surefireArgLine}</argLine>	❌ — ${surefireArgLine} early-binds to empty string before prepare-agent runs
C	(block removed)	✅ — Surefire auto-picks up argLine set by prepare-agent 1

Scenario	<argLine> in coverage profile	Module	jacoco.exec size	index.html existence
A	@{argLine}	certificate-manager	53,232 B	✅
A	@{argLine}	operator-common	266,810 B	✅
B	${surefireArgLine}	certificate-manager	❌ missing	❌ missing
B	${surefireArgLine}	operator-common	266,810 B 2	✅ 2
C	(block removed)	certificate-manager	53,232 B	✅
C	(block removed)	operator-common	266,810 B	✅

Files checked

• <module>/target/jacoco.exec — binary execution data written by the JaCoCo agent during test run
• <module>/target/site/jacoco/index.html — HTML report generated by jacoco:report

Why ${surefireArgLine} became undefined

#10251 removed <propertyName>surefireArgLine</propertyName> from the JaCoCo config, so JaCoCo now writes to the default argLine property instead. The coverage profile was left with ${surefireArgLine} — an undefined property that resolves to empty at POM parse time, silently stripping the JaCoCo agent from Surefire's JVM args.

Removing the surefire block from the coverage profile fixes this by letting Surefire auto-pick up the default argLine that JaCoCo sets.

---

But this is indeed a completely separate issue. Should we open another PR to address it?

Footnotes

1. https://www.jacoco.org/jacoco/trunk/doc/prepare-agent-mojo.html ↩ ↩²

2. operator-common's module-level surefire config always takes precedence over the root coverage profile ↩ ↩²

[scholzj]

@bboyleonp666 That is a rather long and unclear answer for a simple question. Strictly speaking, I do not think the coverage profile is used at all. But I do not understand why it needs to be touched in this PR as part of this work.

[bboyleonp666]

I see your point. Back to the issue itself, there's no need to do that. Let me revert that change.

[scholzj]

LGTM. Thanks.

[scholzj]

/gha run pipeline=acceptance

[github-actions]

⏳ System test verification started: link

The following 2 job(s) will be executed:

• acceptance-amd64 (cncf-ubuntu-4-16-x86)
• acceptance-arm64 (cncf-ubuntu-4-16-arm)

Tests will start after successful build completion.

[github-actions]

❌ System test verification failed: link

[ppatierno]

@bboyleonp666 That is a rather long and unclear answer for a simple question.

I think it's clearly verbosity coming from AI tooling which was not cleaned at all.

@bboyleonp666 if you are using AI (which looks pretty clear to me), given our AI policy https://github.com/strimzi/governance/blob/main/AI_POLICY.md in the governance you should disclose it clearly in the PR description. Thanks.

[bboyleonp666]

@ppatierno thanks for pointing that out. I've added a disclosure in the PR description.

[github-actions]

❌ System test verification failed: link

[scholzj]

I think the system test issue is related to this PR and its changes in some way.

[bboyleonp666]

I tried to run system tests for acceptance group locally and it behaves similarly. It seems that I didn't include the latest change that supports kafka v4.2.1 as in kafka-versions.yaml, which induces the resources never ready issue.
It gets resolved after I rebase my branch.

[ppatierno]

/gha run pipeline=acceptance

[github-actions]

⏳ System test verification started: link

The following 2 job(s) will be executed:

• acceptance-amd64 (cncf-ubuntu-4-16-x86)
• acceptance-arm64 (cncf-ubuntu-4-16-arm)

Tests will start after successful build completion.

[scholzj]

I think it would be pretty weird if rebased fixed this because the tests run against a merge. So I think there will be some other problem there.

[bboyleonp666]

I think you are totally right. I just check the logs of the running system tests. It fails with the same reason again. All waiting for Kakfa/cluster

2026-06-09 13:03:58 [T-701] ERROR [Wait:132] Timeout after 840000 ms waiting for Resource condition: readiness to be fulfilled for resource Kafka/cluster-505d6e32

Investigating in that direction. Do you have any guess that might help?

[scholzj]

I'm afraid I have no idea what the problem is. Especially if it seems to be working for you locally. :-(

Maybe checking the logs once the tests are finished could help to understand if the Kafka cluster did not deployed at all or what the problem was.

[github-actions]

❌ System test verification failed: link