Closed yesamer closed 6 days ago
PR job #2
was: UNSTABLE
Possible explanation: This should be test failures
Please look here: https://ci-builds.apache.org/job/KIE/job/kogito/job/main/job/pullrequest_jobs/job/kogito-runtimes-pr/job/PR-3785/2/display/redirect
Test results:
Those are the test failures:
Thanks @yesamer , but I'm still doubtful about this modification.
Here's from the build logs
2024-11-19T17:57:42.1468110Z Downloading from central: https://repo.maven.apache.org/maven2/com/thoughtworks/xstream/xstream/1.4.20/xstream-1.4.20.pom
2024-11-19T17:57:42.1471968Z Downloaded from central: https://repo.maven.apache.org/maven2/com/thoughtworks/xstream/xstream/1.4.20/xstream-1.4.20.pom (25 kB at 1.6 MB/s)
2024-11-19T17:57:42.1474434Z Downloading from central: https://repo.maven.apache.org/maven2/com/thoughtworks/xstream/xstream-parent/1.4.20/xstream-parent-1.4.20.pom
2024-11-19T17:57:42.2456693Z Downloaded from central: https://repo.maven.apache.org/maven2/com/thoughtworks/xstream/xstream-parent/1.4.20/xstream-parent-1.4.20.pom (44 kB at 2.6 MB/s)
2024-11-19T17:57:42.3465718Z Downloading from central: https://repo.maven.apache.org/maven2/com/thoughtworks/xstream/xstream/1.4.20/xstream-1.4.20.jar
To be clear, I'm not saying that the fix does not work as expected
But IMO, this solution is inherently frail, since, without explicitly excluding xstream from quarkus-junit5:
At the same time, I see that, with the exclude, we would require another modification somewhere else...
@gitgabrio I understand your concern and I agree this is not the ideal solution and in normal conditions it should be avoided, in my opinion, could make sense as a temporary solution but let's wait for other opinions.
Temporary declaring xstream dependency, a version (1.4.20) is transitively imported by Quarkus 3.8 affected by CVE