Steven Gantz created SUREFIRE-1576:
--------------------------------------
Summary: Spring Boot Context Failure using Surefire Plugin and -f
./pom.xml
Key: SUREFIRE-1576
URL: https://issues.apache.org/jira/browse/SUREFIRE-1576
Project: Maven Surefire
Issue Type: Bug
Components: classloading
Affects Versions: 2.22.0
Environment: Ubuntu, RHEL, OSX, W7
Reporter: Steven Gantz
When running the Maven Surefire Plugin under specific circumstances, the Spring
context fails to load properly and presents multiple errors.
I reached out to the Spring boot repository on Github and had the following
discussion: [https://github.com/spring-projects/spring-boot/issues/14649]
The short version is that when running the following command:
{{mvn clean install -f ./pom.xml}}
The classpath is built like so:
{{[file:/Users/awilkinson/Downloads/whacky-pom/./target/test-classes/|file:///Users/awilkinson/Downloads/whacky-pom/target/test-classes/]
[file:/Users/awilkinson/Downloads/whacky-pom/./target/classes/|file:///Users/awilkinson/Downloads/whacky-pom/target/classes/]}}
Below is a comment from a spring boot maintainer:
This looks like a bug in Surefire to me. When the build is run with {{-f
./pom.xml}} that paths in the manifest of the Surefire Booter jar have
extraneous {{/./}} segments in their paths:
The simple solution is to not do ./pom.xml. However, this issue is occurring in
our CI server where most teams use {{-f ./pom.xml}} implicitly as they just
pass that in as the pom path. However, this only happens in projects using
Spring-Data-JPA and a specific list of dependencies.
Is this by design? Is it possible the library is using the paths improperly and
it isn't surefire?
Is this a bug to be fixed?
I think I can patch the CI server to handle this, but it can potentially happen
to anyone. Just looking for feedback and potential action.
On a side note, this is my first foray into any type of open source software
"contribution/interaction" wise, so please feel free to point out anything I've
done incorrectly.
If pointed in the right direction, I'd love to attempt a PR to resolve this
issue.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
