Fixed situation where a changing a managed dependency that does not have an explicit version tag would fail to add a version tag when providing the newVersion option.

[steve-aom-elliott]

What's changed?

• Previously, when you had a POM with a managed dependency that did not have an explicit version tag (because the version was applied to the managed dependency in an external parent artifact), calling ChangeManagedDependencyGroupIdAndArtifactId would fail to make the full needed change. Now it will add the version tag to the managed dependency.

What's your motivation?

This was preventing managed dependencies from being updated correctly.

Still TODO

• A situation that I haven't managed to get correct yet is when you have a managed dependency in a POM (let's call it project A) w/o a version tag, and a direct dependency in a child module (let's call it project B)'s POM also w/o a version tag. In this situation, what appears to be happening right now is that the POM for project A is getting the version number added correctly to the managed dependency, but at the same time, the POM for project B is getting a version number added incorrectly to the direct dependency. RemoveRedundantDependencyVersions in theory should have been able to handle this, but I believe it to not be detecting the change that occurred in project A's POM due to not having re-evaluated the MavenResolutionResult again after the change.
  • Might need some help figuring this one out.

Checklist

• I've added unit tests to cover both positive and negative cases
• I've read and applied the recipe conventions and best practices
• I've used the IntelliJ IDEA auto-formatter on affected files