AWS: smithy.rules and aws.cloudformation aren't generated for users or in aws-kernel/core

[kubukoz]

The namespaces are necessary to compile certain APIs, such as Location. Currently, in order to actually generate them, one has to use smithy4sAllowedNamespaces, which switches the codegen to an allowlist, and now every other namespace also has to be listed.

I think we should either:

• add these to aws-kernel's codegen (but why would we do that if we don't use these classes?), or
• add extra modules that provide them (but it increases the build matrix), or
• change how we prevent the generation of aws.* and smithy.* in CodegenImpl, and e.g. have a third setting like smithy4sExtraNamespaces which works in conjunction with auto-discovery of namespaces (current default when not using smithy4sAllowedNamespaces).

I would say option 1 is the least effort for users so it'd be the pragmatic choice, but it has to first be attempted. If it's too many files, then we'd need to choose a different strategy.

[kubukoz]

Related: disneystreaming/aws-sdk-smithy-specs#9

[Baccata]

smithy.rules is ignored on purpose : https://github.com/disneystreaming/aws-sdk-smithy-specs/blob/main/build.sc#L155-L167

note that the specs found in the AWS SDK are not to be considered official at all, as they are enriched with a bunch of stuff that is irrelevant to the larger purpose (including smithy.rules traits)

I think I'd be okay with generating the aws.cloudformation traits in aws-kernel.

NB : this issue is yet another argument for using dynamic bindings

[kubukoz]

smithy.rules is ignored on purpose : disneystreaming/aws-sdk-smithy-specs@main/build.sc#L155-L167

note that the specs found in the AWS SDK are not to be considered official at all, as they are enriched with a bunch of stuff that is irrelevant to the larger purpose (including smithy.rules traits)

hmm that makes sense. I didn't know we were trimming them out in aws-sdk-smithy-specs. In that case, once that repo's publishing is stable, this shan't be a problem.

I think I'd be okay with generating the aws.cloudformation traits in aws-kernel.

good, let's.

NB : this issue is yet another argument for using dynamic bindings

true, that'd obviate the need for generating aws.cloudformation