NIFI-16202 Removed Mockito warning that appeared when running the nifi build.

[dan-s1]

Summary

NIFI-16202
Without the changes in this PR one can see running

grep -r -i "Mockito is currently" --include="*output.txt" .

from the build directory after running the build will result in many hits e.g.

./nifi-commons/nifi-security-ssl/target/surefire-reports/org.apache.nifi.security.ssl.EphemeralKeyStoreBuilderTest-output.txt:Mockito is currently self-attaching to enable the inline-mock-maker. This will no longer work in future releases of the JDK. Please add Mockito as an agent to your build as described in Mockito's documentation: https://javadoc.io/doc/org.mockito/mockito-core/latest/org.mockito/org/mockito/Mockito.html#0.3

but after running the build with this PR the above grep command will result in nothing. In addition, the Mockito message will not be seen when running any of these tests in Intellij.

The changes in this PR involved the follow changes in the top level pom.xml:

• Placed the configuration that existed for the maven-dependency-plugin in its own execution block
• Added another execution block in the maven-dependency-plugin in order to copy the mockito-core library to the target directory.
• Added an argLine to the maven-surefire-plugin to configure mockito-core as a Java Agent to enable explicit attachment to processes.

Tracking

Please complete the following tracking steps prior to pull request creation.

Issue Tracking

• Apache NiFi Jira issue created

Pull Request Tracking

• Pull Request title starts with Apache NiFi Jira issue number, such as NIFI-00000
• Pull Request commit message starts with Apache NiFi Jira issue number, as such NIFI-00000
• Pull request contains commits signed with a registered key indicating Verified status

Pull Request Formatting

• Pull Request based on current revision of the main branch
• Pull Request refers to a feature branch with one commit containing changes

Verification

Please indicate the verification steps performed prior to pull request creation.

Build

• Build completed using ./mvnw clean install -P contrib-check
  • JDK 21
  • JDK 25

Licensing

• New dependencies are compatible with the Apache License 2.0 according to the License Policy
• New dependencies are documented in applicable LICENSE and NOTICE files

Documentation

• Documentation formatting appears as expected in rendered files

[dan-s1]

@exceptionfactory Do you know why I may be seeing the following errors on the MacOS

[ERROR] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.359 s <<< FAILURE! -- in org.apache.nifi.build.VerifyBuildLocaleTest
[ERROR] org.apache.nifi.build.VerifyBuildLocaleTest.testEnvironmentLocaleMatchesSystemProperties -- Time elapsed: 0.197 s <<< FAILURE!
org.opentest4j.AssertionFailedError: system property - CI_LOCALE:[-Duser.language=ja -Duser.country=JP] ACTUAL:[user.language=en] ==> expected: <true> but was: <false>
	at org.junit.jupiter.api.Assertions.assertTrue(Assertions.java:232)
	at org.apache.nifi.build.VerifyBuildLocaleTest.testEnvironmentLocaleMatchesSystemProperties(VerifyBuildLocaleTest.java:52)

and on the Windows box

[ERROR] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.207 s <<< FAILURE! -- in org.apache.nifi.build.VerifyBuildLocaleTest
[ERROR] org.apache.nifi.build.VerifyBuildLocaleTest.testEnvironmentLocaleMatchesSystemProperties -- Time elapsed: 0.097 s <<< FAILURE!
org.opentest4j.AssertionFailedError: system property - CI_LOCALE:[-Duser.language=fr -Duser.country=FR] ACTUAL:[user.language=en] ==> expected: <true> but was: <false>
	at org.junit.jupiter.api.Assertions.assertTrue(Assertions.java:232)
	at org.apache.nifi.build.VerifyBuildLocaleTest.testEnvironmentLocaleMatchesSystemProperties(VerifyBuildLocaleTest.java:52)

?

I do not think the changes I made should have any bearing on these unit tests. Please advise. Thanks!

[exceptionfactory]

@exceptionfactory Do you know why I may be seeing the following errors on the MacOS

[ERROR] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.359 s <<< FAILURE! -- in org.apache.nifi.build.VerifyBuildLocaleTest
[ERROR] org.apache.nifi.build.VerifyBuildLocaleTest.testEnvironmentLocaleMatchesSystemProperties -- Time elapsed: 0.197 s <<< FAILURE!
org.opentest4j.AssertionFailedError: system property - CI_LOCALE:[-Duser.language=ja -Duser.country=JP] ACTUAL:[user.language=en] ==> expected: <true> but was: <false>
	at org.junit.jupiter.api.Assertions.assertTrue(Assertions.java:232)
	at org.apache.nifi.build.VerifyBuildLocaleTest.testEnvironmentLocaleMatchesSystemProperties(VerifyBuildLocaleTest.java:52)

and on the Windows box

[ERROR] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.207 s <<< FAILURE! -- in org.apache.nifi.build.VerifyBuildLocaleTest
[ERROR] org.apache.nifi.build.VerifyBuildLocaleTest.testEnvironmentLocaleMatchesSystemProperties -- Time elapsed: 0.097 s <<< FAILURE!
org.opentest4j.AssertionFailedError: system property - CI_LOCALE:[-Duser.language=fr -Duser.country=FR] ACTUAL:[user.language=en] ==> expected: <true> but was: <false>
	at org.junit.jupiter.api.Assertions.assertTrue(Assertions.java:232)
	at org.apache.nifi.build.VerifyBuildLocaleTest.testEnvironmentLocaleMatchesSystemProperties(VerifyBuildLocaleTest.java:52)

?

I do not think the changes I made should have any bearing on these unit tests. Please advise. Thanks!

That is a smoke test to ensure locale settings are being based as expected. It points to a missing configuration element in the new plugin definitions.

[dan-s1]

Was this caused by my changes? Is there something I need to do? If so what is it?

[exceptionfactory]

Was this caused by my changes? Is there something I need to do? If so what is it?

Yes, I recommend taking a closer look at the Java arguments to make sure they are being passed as expected

[dan-s1]

Where are you referring to? My changes I believe changed an argline for the surefire plugin. Does that affect the environment variables set?

[exceptionfactory]

Where are you referring to? My changes I believe changed an argline for the surefire plugin. Does that affect the environment variables set?

Yes, see the build.yml workflow that provides an external argLine, which needs to be passed along to any subsequent configuration