Fixing ProjectReload with missing artifacts#7855
Conversation
| <repository> | ||
| <id>central</id> | ||
| <url>https://repo.maven.apache.org/maven2</url> | ||
| </repository> | ||
|
|
||
| <repository> | ||
| <id>gcn</id> | ||
| <url>https://maven.oracle.com/public</url> | ||
| </repository> |
There was a problem hiding this comment.
can this be reproduced without requiring two repos and so many dependencies?
unit tests shouldn't download entire demo applications if it is somehow avoidable.
There was a problem hiding this comment.
Sorry for late response; I completely forgot about this one.
The bug was caught in this configuration / application. I need something that has a parent-POM and some other artifacts in a public repository; I might be able to trim down it a little.
There was a problem hiding this comment.
@mbien I've reduced dependncies in the test data projects and removed custom repositories. I've checked that the test + test data fails in the master; should succeed when fixed implemenation is present here in the branch.
|
Last call, will merge tonight if no objections. |
It was discovered that if
ProjectReload.withProjectStateis used and the project contains a truly unresolvable artifact (i.e. a reference to a local custom build, that can be never downloaded), the priming support will keep telling the project state is not good. The past priming information (with an old timestamp) was incorrectly cached and has been merged with the new MavenProject, but degraded its timestamp ... so it was older than constituent files, which resulted in an inconsistent state right after load.This PR extends the SPI to indicate that the ReloadImplementation should execute whenever previous ReloadImplementations changed anything. It also fixes various conditions with missing artifacts and project (re)loads - see the added test cases.