Blake Li

The original issue was reported in https://github.com/googleapis/gapic-generator-java/issues/1016#issuecomment-1227785726

@diego92sigma6 is still testing a few scenarios based on new requests from dataflow team, let's hold off the release until the tests are done.

Thanks @diegomarquezp for providing the workaround! Adding the service yamls that SpringCodeGen does not need is a signal that it may not be the long term solution. I'm considering `TestProtoLoader`...

In addition, I think we should have a downstream check that verifies the generator changes should not break spring-cloud-gcp, created an issue https://github.com/googleapis/sdk-platform-java/issues/2534 for it.

This is hypothesis scenario, we don't have a service proto that is configured this way. But if they do, the generated code would error out during runtime.

I don't think we have an AIP or similar specification that forbid this scenario, the [comment](https://github.com/googleapis/googleapis/blob/dbfbfdb38a2f891384779a7ee31deb15adba6659/google/api/http.proto#L61-L65) in the proto is the closest thing. Yes you are probably right that it...

> So the proper solution seems not to make the Java generator to work with such proto files (somehow), but to prevent such proto files. Agreed. Maybe it was not...

Can they pass [FixedCredentialsProvider](https://github.com/googleapis/sdk-platform-java/blob/main/gax-java/gax/src/main/java/com/google/api/gax/core/FixedCredentialsProvider.java) instead of NoCredentialProvider to StorageOptions? See an example [here](https://github.com/googleapis/google-cloud-java/tree/main?tab=readme-ov-file#existing-oauth2-access-token)

> Are there any cons with using this workaround? This is not ideal, but I think it's fine for now. Currently, if we should enable direct path is decided on...

> java-iam/README.md is excluded from templating, should we not generate it? I don't think it makes sense for both java-iam and java-common-protos to have READMEs, I think we can remove...