hpi:run uses wrong jpi/hpl from .jenkins-hpl-map

[jgreffe]

https://issues.jenkins.io/browse/JENKINS-70329

Check if the resolved the.hpl from /Users/xxx/.jenkins-hpl-map are contained within the current maven root project. If not, logs a WARN instead of an INFO.

• [x] Make sure you are opening from a topic/feature/bugfix branch (right side) and not your main branch!
• [x] Ensure that the pull request title represents the desired changelog entry
• [x] Please describe what you did
• [x] Link to relevant issues in GitHub or Jira
• [ ] Link to relevant pull requests, esp. upstream and downstream changes
• [x] Ensure you have provided tests - that demonstrates feature works or fixes the issue

[jglick]

I cannot recall why it was in the current order to begin with.

One reason I remember now: in the normal case that the snapshot version changes (in the case of core or a plugin using maven-release-plugin rather than CD), you would otherwise get an ever-growing list of entries with the same groupId / artifactId but different versions, with no garbage collection. The current scheme at least ensures that after a version change (in the same checkout directory), the stale entry is overwritten.

An alternative scheme which would address JENKINS-70329 simply while avoiding an ever-growing file might be to write out directory / GAV pairs in reverse chronological order (implies using some format other than Properties, which discards order; see also #428) and discard anything beyond the most recent 100 or 1000 or whatever.

Another solution would be to invert the map but use GA rather than GAV as the key, and include the version in the value alongside the file path. It is after all unlikely that you would switch back and forth between projects using different versions of the same snapshot dependency and expect mvn hpi:run or mvn test to work in each without reinstalling dependencies.