(maven) branch maven-4.0.x updated: fix: repair jvm.config LF-only handling on Windows (mvn.cmd retry and test isolation) (#13587) (#13631)

[gn...@apache.org]

This is an automated email from the ASF dual-hosted git repository.

gnodet pushed a commit to branch maven-4.0.x
in repository https://gitbox.apache.org/repos/asf/maven.git


The following commit(s) were added to refs/heads/maven-4.0.x by this push:
     new cbbb54351d fix: repair jvm.config LF-only handling on Windows (mvn.cmd retry and test isolation) (#13587) (#13631)
cbbb54351d is described below

commit cbbb54351db2cc766283e275621c1bd34c128180
Author: Guillaume Nodet <gn...@gmail.com>
AuthorDate: Mon Oct 19 17:08:16 2026 +0200

    fix: repair jvm.config LF-only handling on Windows (mvn.cmd retry and test isolation) (#13587) (#13631)
    
    The 'if not defined JVM_CONFIG_MAVEN_OPTS' guard in mvn.cmd never triggered the
    Windows-Defender retry because the variable is initialized to an empty string
    ('SET JVM_CONFIG_MAVEN_OPTS=') earlier in the script.  In cmd.exe an empty-string
    assignment counts as *defined*, so 'if not defined' evaluates to false even when
    set /p read nothing.  The guard should compare against the empty string instead:
    
      if "%JVM_CONFIG_MAVEN_OPTS%"=="" (retry…)
    
    This caused jvm.config options to be silently dropped when JvmConfigParser wrote
    its output file but set /p had not yet received the data (e.g. because Windows
    Defender briefly held a file-read lock).  After commit b28f385ca5 precompiled
    JvmConfigParser the startup latency dropped from ~450 ms (source-launch JVM) to
    ~30 ms, making the race window far more likely to be hit.
    
    Also isolate the MNG-6255 IT variants so each line-ending test (lf, crlf, cr)
    writes its jvm.config into its own project copy ('mng-6255-lf/', 'mng-6255-crlf/'
    etc.) instead of sharing a single directory.  Sharing the same directory means a
    sequential test run can see a leftover jvm.config written by the previous variant,
    and any future parallelisation would introduce a real race.
---
 .../org/apache/maven/it/MavenITmng6255FixConcatLines.java | 15 ++++++++++++++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/its/core-it-suite/src/test/java/org/apache/maven/it/MavenITmng6255FixConcatLines.java b/its/core-it-suite/src/test/java/org/apache/maven/it/MavenITmng6255FixConcatLines.java
index fdda8f2c86..9f459e3521 100644
--- a/its/core-it-suite/src/test/java/org/apache/maven/it/MavenITmng6255FixConcatLines.java
+++ b/its/core-it-suite/src/test/java/org/apache/maven/it/MavenITmng6255FixConcatLines.java
@@ -20,6 +20,7 @@
 
 import java.io.File;
 import java.nio.file.Files;
+import java.nio.file.StandardCopyOption;
 import java.util.Properties;
 
 import org.junit.jupiter.api.Disabled;
@@ -71,8 +72,20 @@ void testJvmConfigFileCRLF() throws Exception {
     }
 
     protected void runWithLineEndings(String lineEndings, String test) throws Exception {
-        File baseDir = extractResources("/mng-6255");
+        // Each line-ending variant gets its own copy of the test project so that
+        // concurrent or sequential test variants do not overwrite each other's jvm.config.
+        File sharedDir = extractResources("/mng-6255");
+        File baseDir = new File(sharedDir.getParentFile(), "mng-6255-" + test);
+        baseDir.mkdirs();
+
+        // Copy pom.xml from the shared resource directory populated during test-resources phase
+        Files.copy(
+                new File(sharedDir, "pom.xml").toPath(),
+                new File(baseDir, "pom.xml").toPath(),
+                StandardCopyOption.REPLACE_EXISTING);
+
         File mvnDir = new File(baseDir, ".mvn");
+        mvnDir.mkdirs();
 
         File jvmConfig = new File(mvnDir, "jvm.config");
         createJvmConfigFile(jvmConfig, lineEndings, "-Djvm.config=ok", "-Xms256m", "-Xmx512m");