Match the package layout of contemporary providers?

[negz]

Currently the package layout of the providers we generate from Terraform is fairly different from our hand curated (or ACK generated) providers - e.g. type definitions and logic for each managed resource are under generated/resources/, while contemporary providers follow a fairly typical convention (perhaps from kubebuilder boilerplate?) of keeping types under apis/ and logic elsewhere (we've been gravitating toward putting it all under internal/ rather than cargo-culting the pkg/ convention).

Is there rationale behind this divergence, or is it mostly subjective?

[kasey]

The initial thinking was that we may wind up mixing hand-written packages with generated packages, so we should separate generated resources into a different tree. I am happy to look at putting types into an apis package. Breaking out the other components of code gen (initialization/registry, decode/encode/compare) into a different package under internal would also be possible. Because the controller for terraform generated providers is generic, I personally find putting everything relating to the generated types in one place makes it all more discoverable and reduces mental overhead, but if there is a good reason to move it around, that can be done.

[negz]

Got it. FWIW I found this provider's layout surprising and had to take some time getting acquainted with how it all fit together that I don't typically need to take when looking at a new Crossplane provider (or controller-runtime-based project in general). That said, I'm conscious that these Terraform providers are a pretty different beast. Consider this a request for a sanity check that we're diverging for good reason rather than a request that we actually change anything.