Remove v1 CloudWatch module

[shakuzen]

See #1165. Users should use the new v2 module instead, which uses the AWS SDK v2 underneath.

[shakuzen]

I had originally scheduled this for 2.0.0 being conservative about removing a module in a minor version release, but I'm wondering if such caution is warranted here, especially given the SaaS nature of CloudWatch.

Seeking feedback from Micrometer / CloudWatch users
Is there any reason a CloudWatch user would have trouble using the micrometer-registry-cloudwatch2 module with AWS SDK v2 now instead of the v1 module with AWS SDK v1?

If it's not a problem, I would like to stop publishing (and therefore maintaining the code for) the v1 module starting from the Micrometer 1.5 release.

[jkschneider]

Would we leave the coordinates micrometer-registry-cloudwatch2 or dual publish the V2 module to micrometer-registry-cloudwatch?

[jkschneider]

Maybe a good lesson for the future, we should keep V2 registry implementations in the same module and use Gradle feature variants or something instead.

[shakuzen]

Looking at the list of unimplemented features for parity in the v2 AWS SDK, I'm starting to think deprecating our v1 version may have been premature. It might even make sense to remove deprecation until AWS gives some indication they're moving away from supporting v1 of the SDK.

Maybe a good lesson for the future, we should keep V2 registry implementations in the same module and use Gradle feature variants or something instead.

If we could cleanly do that without complicating configuration or breaking compatibility, it would be nice. That's a big IF a lot of times, though.

I looked through the documentation on Gradle feature variants, but I don't understand how it would improve the situation. I suppose we'd copy the source files from the v2 module into the original module in a different source set, which seems hardly different from a maintenance/organization perspective. For consumers, if we're publishing Gradle metadata (we don't currently) and they're using Gradle (a version that supports the metadata), they'd have to consume the cloudwatch module in a different way (requireCapability) than up until now. I worry about the support burden this will generate. For Maven users, consuming feature variants seems to use artifact classifier, which is also not very different than just using a different artifact ID.

Would we leave the coordinates micrometer-registry-cloudwatch2 or dual publish the V2 module to micrometer-registry-cloudwatch?

I think leaving the coordinates cloudwatch2 will be least surprising for users. Maybe in Micrometer 2.0 we could reclaim the original artifact name with the v2 implementation, but it depends on the state of the AWS SDK, which seems like its v1 will be around and in use for quite a while.

[jonatan-ivanov]

Linking in: awspring/spring-cloud-aws#116

[shakuzen]

Since Spring Cloud AWS has had support for the AWS SDK v2 for some time now, I'm wondering if it's a reasonable time to revisit removal of this module. No users have come to this issue to complain, though that may be more a matter of not knowing about this issue. We have, however, largely stopped fixing things in the deprecated module and only have been applying fixes to the v2 module. We can try asking on Slack and social media and if we don't find a good reason to not, we'll try removing for the 1.13.0-M2 release which perhaps will give a chance for users to complain about the module missing if they can't migrate to v2 for some reason.