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.
• Logic has also been adjusted within ChangeDependencyGroupIdAndArtifactId to prevent also adding the version tag to the direct dependency that is managed in the scenario that we end up changing the managed dependency as well.
• Guard added against considering all resolved managed dependencies as being managed for the purposes of an existing managed dependency in favour of considering only requested, defined, managed dependencies upwards through the parents.

What's your motivation?

This was preventing managed dependencies from being updated correctly.

Anything else to consider?

If we have a local parent POM that has a requested managed dependency on A, and the child POM has a requested managed import dependency that would expand to include a managed dependency on A once resolved, should we not be able to affect change on the managed dependency because the closest one could be the one managed by the BOM imported managed dependency in the child POM?

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