Fix: resolve relative classpath elements against the fork's working dir#3333
Merged
olamy merged 6 commits intoJun 6, 2026
Merged
Conversation
Contributor
Author
|
Hi everyone, this PR from March 27 is still open — could you please take a moment to review it? Thanks. |
olamy
reviewed
Jun 4, 2026
| throws SurefireBooterForkException { | ||
| cli.addEnvironment("CLASSPATH", join(toCompleteClasspath(config).iterator(), File.pathSeparator)); | ||
| List<String> classpath = toCompleteClasspath(config); | ||
| cli.addEnvironment("CLASSPATH", join(classpath.iterator(), File.pathSeparator)); |
Member
There was a problem hiding this comment.
please limit non needed changes or point via a comment the real fix
olamy
reviewed
Jun 4, 2026
olamy
reviewed
Jun 4, 2026
cwegener-79
force-pushed
the
bugfix/relativeAddtionalClasspathElements
branch
from
7f40092 to
03ceb2f
Compare
…irectory When Surefire uses a manifest-only JAR to pass the classpath (default on Windows and for long classpaths), Class-Path entries in the manifest are relative to the manifest JAR's parent directory - a temp directory, not the fork's working directory. A relative additionalClasspathElement (e.g. ../resources) was written as-is into the manifest, where the JVM resolved it against the temp directory instead of the fork's workingDirectory, silently pointing at the wrong location. Fix: JarManifestForkConfiguration now resolves relative classpath elements against the fork's working directory before computing their manifest-relative representation. All resolveClasspath() implementations receive the resolved working directory as a new parameter. In direct classpath mode (ClasspathForkConfiguration) no change in behavior is needed as the JVM already resolves -cp entries against its own CWD. Adds unit test (ForkConfigurationTest) and integration test (AdditionalClasspathForkIT / additional-classpath-relative-workdir) to guard against regression.
cwegener-79
force-pushed
the
bugfix/relativeAddtionalClasspathElements
branch
from
03ceb2f to
c5d24a2
Compare
Member
|
@cwegener-79 thanks for the last changes. just need now a last |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
When Surefire uses a manifest-only JAR to pass the classpath (default on Windows
and for long classpaths), Class-Path entries in the manifest are relative to the
manifest JAR's parent directory - a temp directory, not the fork's working directory.
A relative additionalClasspathElement (e.g. ../resources) was written as-is into
the manifest, where the JVM resolved it against the temp directory instead of the
fork's workingDirectory, silently pointing at the wrong location.
Fix: JarManifestForkConfiguration now resolves relative classpath elements against
the fork's working directory before computing their manifest-relative representation.
All resolveClasspath() implementations receive the resolved working directory as a
new parameter. In direct classpath mode (ClasspathForkConfiguration) no change in
behavior is needed as the JVM already resolves -cp entries against its own CWD.
Adds unit test (ForkConfigurationTest) and integration test
(AdditionalClasspathForkIT / additional-classpath-relative-workdir) to guard
against regression.
Testing
Unit tests pass (
mvn clean install).Integration tests (
-PrunIts) could not be executed due to proxy restrictions in my build environment.Known build issue
mvn clean installfails with the RAT plugin reporting unapproved licenses on generated files insidetarget/subdirectories (e.g.checkstyle-cachefile,spotless-index,.plxarc). This appears to be a pre-existing gap in the RAT configuration —target/is not explicitly excluded. The following addition to the<excludes>block in the rootpom.xmlwould fix it:Build can be verified in the meantime with:
mvn clean install -Drat.skip=true