Add DependencyManagement handling

[Jenson3210]

What's changed?

By using a Trait we can both match dependencyManagement sections from recipe perspectives. I also wrote a method that updates the Trait's cursor with an updated dependencyManagement. We can have several more overload methods that call this one with null. Passing null for group, artifact or version makes these fields untouched.

What's your motivation?

It has been introduced also in the ChangeDependency recipe as an optional boolean (which defaults to true) as that is also how it is done in maven recipe/equivalents

• Fix Gradle - Add tests for update in dependencyManagement #5304

Anything in particular you'd like reviewers to focus on?

I tried to minimize code duplications as it was really becoming a lot of copy pasting / error prone to changes.
I stopped at a point where I feel if we further try to remove duplications, we end up in a hard to follow code flow.

Anyone you would like to review specifically?

@shanman190 or @sambsnyd would be great for an early/conceptual review. Please do not focus on code duplications etc yet. I want to fail fast before spending time in optimizing.

Have you considered any alternatives or workarounds?

As suggested by @shanman190, I went for a postVisit recipe that is optionally adding the dependencyManagement to be aligned with maven equivalents.
ATM, the Trait does not allow for templated strings yet as we would need scanning phases for that so want to come up with support for no-templates strings first and then add templated strings in a separate PR later if required.

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

[shanman190]

When I think about the logistics of it, it feels like ChangeDependency should be altering an external dependency that the project explicitly pulls in. The Spring Dependency Management plugin is more about declaring a managed dependency which at least to me is more akin to declaring a dependency constraint. Neither has any effect upon dependencies until it exists within the dependency graph.

What if we introduced a ChangeManagedDependency and had it update the constraints and dependency management sections? Like in Maven managed dependency has no effect until the dependency is actually present, so I think this aligns more closely in expectations.

[Jenson3210]

@shanman190,

• you would then have to call both these recipes from everywhere you want to bump a dependency? Or would you still call it from the ChangeDependency?
  Are we then not also going to have to create UpgradeManagedDependencyVersion etc?
  Or do they all delegate to that one?
• You then mean not to put the actual dependencyManagement change in the Trait but in a recipe? Or is it fine to keep it in the Trait and then from that recipe for the Spring's dependency management part use the Trait over there and for constraints use another visitor/Trait and...?

[shanman190]

Here's my analysis of rewrite-maven as a parallel:

• maven.AddDependency - only add direct dependency
• maven.AddManagedDependency - only add managed dependency
• maven.ChangeDependencyGroupIdAndArtifactId - has option defaulted to true to change managed dependencies as well via doAfterVisit
• maven.ChangeManagedDependencyGroupIdAndArtifactId - only change managed dependency
• maven.RemoveDependency - only remove direct dependency
• maven.RemoveManagedDependency - only remove managed dependency
• maven.UpgradeDependencyVersion - upgrades a direct or managed dependency

So it would make sense I suppose to follow the established pattern. Honestly, I didn't realize that the maven.ChangeDependencyGroupIdAndArtifactId had been updated to effect managed dependencies by default. I probably would have kept them separate following the single responsibility principle myself, but at least the recipes are separate with the one invoking the other when requested.

I think having the trait is fine, but I think the design that I think would work best is a gradle.ChangeManagedDependency which encompasses changing a constraint using the trait from #5604 and then your dependency management trait here. Then we update gradle.ChangeDependency to have an option akin to the Maven variant and when that option is true execute to the gradle.ChangeManagedDependency recipe in a doAfterVisit.

[Jenson3210]

I still need to find a way to have this here without it failing but without @JsonCreator as @jkschneider mentioned using @JsonCreator is to be avoided. I looked at the other maven counterpart, but there it is done using the annotation.

[shanman190]

callout: Not a part of this PR, but this may be an improvement that we can make for the GradleDependency trait as well.

[Jenson3210]

👍 Leaving this open for now so that we can create a new issue from this comment later on

[shanman190]

As @timtebeek confirmed for me, we're no longer going to use the factory pattern going forward, so we can drop this method.