A few comments below, and just a thought (this could totally be a separate pr if we want it): You probably started out from ClientLibraryPackageInfoComposer.java for SpringPackageInfoComposer.java and cleaned out irrelevant contents. What if we keep the descriptions for each service like in here, remove the samples, and at the bottom, add a sample to use along the lines of: "You can inject auto-configured service bean to your Spring Boot application with annotation based configuration @Autowired [serviceBean] or Constructor Injection "

@zhumin8 Ah I think that would be helpful! One concern here might be that ClientLibraryPackageInfoComposer has logic for formatting service descriptions that is not currently exposed, so copying it could run us into inconsistency if that part of gapic generator code gets updated in the future (though those lines haven’t been modified for a while).

A couple of possible approaches here come to mind, in order of estimated effort. Let me know if you have any preferences or suggestions?

1. We could skip the service description and just list each service client name, followed by the Spring-specific snippet
2. We could copy over service description logic from ClientPackageInfoComposer, and keep SpringPackageInfoComposer updated if this ever changes (any discrepancy would also only impact generated javadoc and not code)
3. We could possibly refactor ClientPackageInfoComposer to expose service description logic for reuse? (This option would definitely warrant a separate PR)

I am inclined to option 3.
But either way, you are right, it could be done in a separate PR. Let's get this merged in and talk about it separately.

I am inclined to option 3. But either way, you are right, it could be done in a separate PR. Let's get this merged in and talk about it separately.

Sounds good!

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
3 Code Smells

82.1% Coverage
0.7% Duplication