Add Spring Cloud Contract Verifier Plugin when the user has added Cloud Contract Verifier about start.spring.io

[snicoll]

This might require keeping information on the verifier version somewhere apart (maybe here), since the dependencies within buildscript probably will not work with dependencyManagement.

What is the difference between spring-cloud-contract.version and verifier_version ? Are they ultimately referring to the same version?

How about using springCloudContractVersion for Gradle, that would be consistent with what we're doing atm.

The annoying issue is that we have to map a release train to a spring cloud contract version. I really would like avoid doing that if possible as it increases the maintenance on our side and the risk of inconsistency.

[OlgaMaciaszek]

The annoying issue is that we have to map a release train to a spring cloud contract version

Yes, that's what I meant - this is the Spring Cloud Contract version indeed, but we would probably have to map it.

[snicoll]

Correct but I am not keen to hardcode the mapping from Spring Cloud release train version to Spring Cloud contract version.

Do you have a proposal to solve this part? If so, we might need to move this one to the library as there is a missing feature we need to implement first.

[OlgaMaciaszek]

To consider: do not set up the plugin if Spring Rest Docs selected as a dependency.

[OlgaMaciaszek]

There is no way of simply deducing the plugin version from the release train, however, we are able to automate getting the plugin version from the Release Train - we do such things with our releaser tool, but it requires doing a call to github, parsing appropriate pom and getting the version. I could add this logic somewhere to initialzr. Alterantively, we could add another field in the config yaml and then just create a PR to update it automatically with the releaser whenever we run a new release. @snicoll would that be anacceptable solution?

[snicoll]

@OlgaMaciaszek thanks for the feedback. Can you share the code that would be required to get the version from the release train? If we implement something, I'd love to get some sort of generic feature (i.e. parsing boms and extracting relevant versions).

We can be pragmatic and consider the PR solution that would make sure it is consistent and implement a better solution later. Let's see the code and we can take it from there.

[OlgaMaciaszek]

@snicoll ok, will work on it next week and share the code here.

[mbhave]

Closing in favor of PR #154 .