argLine problems since 1.15.4

[lennart-bos]

Since 1.15.4 the following fatal error appears when running mvn org.pitest:pitest-maven:mutationCoverage:
PIT >> INFO : MINION : Error: could not open '{argLine}'

Probably caused by this change in 1.15.4: #1289

It probably relates to my Surefire config, which I need to workaround this issue: mockito/mockito#3037

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-surefire-plugin</artifactId>
  <configuration>
    <argLine>@{argLine} -XX:+EnableDynamicAgentLoading</argLine>
  </configuration>
</plugin>

Note that it works fine if I run mvn test org.pitest:pitest-maven:mutationCoverage. Unfortunately, in my CI/CD pipeline, test and mutationCoverage are split into two separate stages.

[hcoles]

Thanks for the report.

Looks like property replacement isn't being done for args taken from surefire. Fortunately it should be an easy fix, will hopefully get a release out today or tomorrow.

[hcoles]

Fix released in 1.15.5

[glennhcc]

I still see this issue with 1.15.7.

17:31:44 PIT >> INFO : MINION : Error: Could not find or load main class ${surefire.jacoco.args}
17:31:44 PIT >> INFO : MINION : Caused by: java.lang.ClassNotFoundException: ${surefire.jacoco.args}

[hcoles]

Could you put together a minimal project that reproduces the issue?

[glennhcc]

@hcoles Sorry, I don't think I can quickly create a project that recreates the issue. Here is some more info from the stack trace if useful:

[ERROR] Failed to execute goal org.pitest:pitest-maven:1.15.7:mutationCoverage (default-cli) on project trading-provider-integral-service: Execution default-cli of goal org.pitest:pitest-maven:1.15.7:mutationCoverage failed: Coverage generation minion exited abnormally! (MINION_DIED)
[ERROR]
[ERROR] Please copy and paste the information and the complete stacktrace below when reporting an issue
[ERROR] VM : OpenJDK 64-Bit Server VM
[ERROR] Vendor : Eclipse Adoptium
[ERROR] Version : 21.0.1+12-LTS
[ERROR] Uptime : 23285
[ERROR] Input ->
[ERROR] 1 : -Dclassworlds.conf=/Users/xxx/.sdkman/candidates/maven/current/bin/m2.conf
[ERROR] 2 : -Dmaven.home=/Users/xxx/.sdkman/candidates/maven/current
[ERROR] 3 : -Dlibrary.jansi.path=/Users/xxx/.sdkman/candidates/maven/current/lib/jansi-native
[ERROR] 4 : -Dmaven.multiModuleProjectDirectory=/Users/xxx/tcc/xxx-xxx-xxx
[ERROR] BootClassPathSupported : false
[ERROR]
[ERROR]
[ERROR] Please copy and paste the information and the complete stacktrace below when reporting an issue
[ERROR] VM : OpenJDK 64-Bit Server VM
[ERROR] Vendor : Eclipse Adoptium
[ERROR] Version : 21.0.1+12-LTS
[ERROR] Uptime : 23286
[ERROR] Input ->
[ERROR] 1 : -Dclassworlds.conf=/Users/xxx/.sdkman/candidates/maven/current/bin/m2.conf
[ERROR] 2 : -Dmaven.home=/Users/xxx/.sdkman/candidates/maven/current
[ERROR] 3 : -Dlibrary.jansi.path=/Users/xxx/.sdkman/candidates/maven/current/lib/jansi-native
[ERROR] 4 : -Dmaven.multiModuleProjectDirectory=/Users/xxx/tcc/xxx-xxx-xxx
[ERROR] BootClassPathSupported : false

[hcoles]

Hi @glennhcc

If you are not able to provide a project that reproduces this, it is unlikely that the issue will be fixed. While it may be difficult for you to create a project that reproduces the issue, it is orders of magnitude harder for me to do so as I have no access to the code and environment where the problem first occurred.

The pitest test suite contains a basic test that surefire args are replaced without creating errors

https://github.com/hcoles/pitest/blob/master/pitest-maven-verification/src/test/resources/pit-surefire-excludes/pom.xml#L40

As this simple case does not reproduce the problem, details of what is happening in your codebase are required to reproduce.

[glennhcc]

@hcoles I understand. Thank you for attention on this. I will try to progress it from my side. We have projects where we do not see this issue in addition to this one where we do. I will try to narrow down the difference.

Currently I am trying to see the runtime value of surefire argLine.

[glennhcc]

@hcoles changing $ to @...

<argLine>${surefire.jacoco.args}</argLine>
to
<argLine>@{surefire.jacoco.args}</argLine>
allowing late replacement of the properties resolves the error.

Not sure if this is any help in identifying the underlying cause.

[hcoles]

Thanks, I think that probably identifies the issue. It looks like the surefire config is being pulled out by pitest without the standard maven variable substitution.

[hcoles]

@glennhcc did the 1.15.8 release resolve the issue for you?

[nicwaters823]

Just to add a bit of info, observed the same issue with two repositories I work on. exact same error with both, only with this version or later.

we had 'surefireArgLine' set to allow jacoco and surefire to work together properly, luckily in our case it turns out the newer version of both of those doesn't require that config set, so I just removed it and then Pitest worked fine
(I did try the suggested workaround '@' not '$') and didn't work in our case)

[GhilesA]

@hcoles issue still present in 1.16.1

[hcoles]

@GhilesA If you can provide a minimal project that reproduces the issue, I can take a look.

[GhilesA]

@hcoles thanks for the quick reply !
You can find a minimal project here https://github.com/GhilesA/pitest_1292_project/tree/main.
After a mvn clean install + execution of the mutationCoverage from pitest plugin you get the same error.
Removing the <argLine>@{argLine} -XX:+EnableDynamicAgentLoading</argLine> configuration of surefire makes it work but it's requiered in my project

[hcoles]

I just checked that project out and ran

mvn test-compile org.pitest:pitest-maven:mutationCoverage

I did not encounter any errors.

Possibly the issue is only with certain maven versions? I was using 3.9.6.

[hcoles]

Also working with maven 3.2.5

What OS are you using?

[GhilesA]

I'm using maven 3.9.6 too, i even tried on 3.9.7
I don't know if this can help but i am running all this with an openJDK 21 on an ubuntu 20. Same problem on my CI pipeline. I can check it's os and versions too

lsb_release -a :

Description:	Ubuntu 20.04.2 LTS
Release:	20.04
Codename:	focal

as a complement the stack error :

[ERROR] Please copy and paste the information and the complete stacktrace below when reporting an issue
[ERROR] VM : OpenJDK 64-Bit Server VM
[ERROR] Vendor : Oracle Corporation
[ERROR] Version : 21.0.1+12-29
[ERROR] Uptime : 18293
[ERROR] Input -> 
[ERROR]  1 : -Dhttps.protocols=TLSv1.2
[ERROR]  2 : -Dclassworlds.conf=/home/user_10/soft/apache-maven-3.9.7/bin/m2.conf
[ERROR]  3 : -Dmaven.home=/home/user_10/soft/apache-maven-3.9.7
[ERROR]  4 : -Dlibrary.jansi.path=/home/user_10/soft/apache-maven-3.9.7/lib/jansi-native
[ERROR]  5 : -Dmaven.multiModuleProjectDirectory=/home/user_10/pitest-error
[ERROR] BootClassPathSupported : false
[ERROR] 
[ERROR] 
[ERROR] Please copy and paste the information and the complete stacktrace below when reporting an issue
[ERROR] VM : OpenJDK 64-Bit Server VM
[ERROR] Vendor : Oracle Corporation
[ERROR] Version : 21.0.1+12-29
[ERROR] Uptime : 18295
[ERROR] Input -> 
[ERROR]  1 : -Dhttps.protocols=TLSv1.2
[ERROR]  2 : -Dclassworlds.conf=/home/user_10/soft/apache-maven-3.9.7/bin/m2.conf
[ERROR]  3 : -Dmaven.home=/home/user_10/soft/apache-maven-3.9.7
[ERROR]  4 : -Dlibrary.jansi.path=/home/user_10/soft/apache-maven-3.9.7/lib/jansi-native
[ERROR]  5 : -Dmaven.multiModuleProjectDirectory=/home/user_10/pitest-error
[ERROR] BootClassPathSupported : false

[GhilesA]

by re-reading you comment i think i got the difference, I'm running mvn pitest:mutationCoverage and not mvn test-compile pitest:mutationCoverage. Indeed with your command it works ! I will check on my pipeline
I am not sure on the implication. Is it required to add test-compile ? I though doing an install before the command was sufficient ^^'

[hcoles]

I discovered the same thing as you were typing that.

Running

mvn test-compile org.pitest:pitest-maven:mutationCoverage

Works

Running

mvn org.pitest:pitest-maven:mutationCoverage

Reproduces the error.

I've not double checked, but I suspect that binding pitest to a lifecyle phase in the recommended fashion will also work.

I'll have to dig into the this to understand exactly what is going on.