fp024 commented on issue #395: URL: https://github.com/apache/maven-wrapper/issues/395#issuecomment-4050690931
Hi, Thank you for the confirmation. I previously mentioned in the document linked in the PR that Jenkins might need to run on an x86 JDK when an x86 build is required in an x64 environment. However, as you suggested, setting `MAVEN_USER_HOME` manually seems like a much better approach: ```cmd set MAVEN_USER_HOME=%WORKSPACE%\.m2 mvnw clean package ``` While setting `MAVEN_USER_HOME` to the workspace is a straightforward solution, it does result in each Jenkins x86 job having its own .m2 folder. To reduce this redundancy, another option worth considering is defining a dedicated, independent path for x86 Maven on the Windows server. I believe the root cause of the issue is as follows: When Jenkins itself runs on an x64 JDK, the PowerShell code within mvnw.cmd runs as a 64-bit process, creating the wrapper under the System32 path (`C:\Windows\System32\config\systemprofile\.m2\wrapper`). However, if the build then uses an x86 JDK, the wrapper attempts to find the required JAR libraries in `C:\Windows\SysWOW64\config\systemprofile\.m2\wrapper`, leading to a ClassNotFoundException due to Windows file system redirection. Therefore, setting `MAVEN_USER_HOME` to a path independent of the system profile is a far more practical solution. My previous idea of running a separate Jenkins instance with an x86 JDK seems unnecessarily complicated in comparison. 😅 Thank you! #### References * https://github.com/fp024/win-file-link-test/blob/main/jenkins-test_en.md -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
