-
Notifications
You must be signed in to change notification settings - Fork 874
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix cycle in problem reporter with unreachable artifacts. #6197
Conversation
The ProblemReporterImpl commit alone is suffcient to fix #6176. I am a little nervous about the SimpleLocalRepository > EnhancedLocalRepository change as it might affect different operations in Maven; but unless this is used, the If some problems arise, this 2nd commit could be safely reverted - resulting in 2nd cycle in ProblemReporterImpl. |
the second commit appears to be the cause of the test failures. I ran a quick local test and they appear to pass using only the first commit. |
Tested with the original problematic maven project and the constructed testcase from the issue and seems to work as it should. Thank you. |
I'll take care of the tests tomorrow / till Monday. Either adapt code (tests) to the suddenly-working artifact resolution, or discard the embedder change. |
adding all-tests label since who knows what else uses the embedder/model indirectly |
…epository chaching.
5462c82
to
e2a14bf
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Checked again and still works 👍
The behavioral change of the #resolve
method seems reasonable as both exceptions are checked exceptions so users are clearly warned. The code indicated, that the exception should have been thrown, so the fix brings the code into the intended line.
thanks everyone, merging in an hour or two so that it doesn't miss the deadline. |
There was a bug in the loop that causes the values NOT to be cached when the loop exited unsuccessfully, so the detection happened over and over again - computation intensive. This PR makes just one repeated attempt to resolve the artifacts, then reports whatever results are computed.
The reported error was made possible also because simple file-exists check is not enough: in the situation described by #6176, the artifact file physically exists locally (so priming detection evaluated that as an inconsistency and looped again), but is actually refused by Maven, as it is recorded to belong to a remote repository, but was never downloaded from there. The changes to
MavenEmbedder
use EnhancedLocalRepository that checks that thoroughly (the same way as Maven does during build). In additionMavenEmbedder.resolve()
method never threw exceptions declared in the signature: partly they were swallowed by Maven library (inDefaultArtifactResolver
) and partially they were ignored if present inresult.getExceptions()
- this affected existing clients that do exception hadling.