feat(bazel): detach spring bazel rules

[diegomarquezp]

This allows spring autoconfig generation to be called from a new rule "java_gapic_spring_library" that is independent from java_gapic_library.

NOTE: The following instructions are for local tests only. Definitive modifications in googleapis are mainly made from rules_gapic's BUILD file generator

For example, in googleapis/google/cloud/vision/v1, we can modify BUILD.bzl by adding:

load(
    "@com_google_googleapis_imports//:imports.bzl",
    "java_gapic_assembly_gradle_pkg",
    "java_gapic_library",
    "java_gapic_spring_library", # defined and explained below
    "java_gapic_test",
    "java_grpc_library",
    "java_proto_library",
)
...
java_gapic_spring_library(
    name = "vision_java_gapic_spring",
    srcs = [":vision_proto_with_info"],
    gapic_yaml = "vision_gapic.yaml",
    grpc_service_config = "vision_grpc_service_config.json",
    service_yaml = "vision_v1.yaml",
)

In googleapis/repository_rules.bzl we need to add a switch and enable spring rules from gapic-generator-java/rules_java_gapic/java_gapic_spring.bzl:

    rules["java_gapic_spring_library"] = _switch(
        java and grpc and gapic,
        "@gapic_generator_java//rules_java_gapic:java_gapic_spring.bzl",
    )

Then build from googleapis:

bazel build //google/cloud/vision/v1:vision_java_gapic_spring

Which will generate the files:

vision_java_gapic_spring_raw.srcjar
vision_java_gapic_spring_raw.srcjar.zip
vision_java_gapic_spring-spring.srcjar # formatted

[diegomarquezp]

Force pushed rebase on current autoconfig-gen-draft2

[zhumin8]

Two quick notes below.
And a more general question for @blakeli0: about the resources jar processing portion in java_gapic_library here that Diego did not bring into spring rule: It seems to me it's only needed for client library to be used in java_gapic_pkg.bzl steps to produce a gapic-[package name]-java-resources.tar.gz with a build.gradle. IIUC that gradle file is not used in the post process of generating pom file, does it mean that all related logic can be potentially cleaned-up in gapic-generator itself in future?

[zhumin8]

I suppose this is derived from _java_gapic_library() in java_gapic.bzl and you removed a couple of options. Can you double check if they don't affect sping-codegen for us?
E.g. I noticed transport is removed, If I get it right, this is where transport is specified as grpc or grpc+rest or rest, which get parsed in and eventually plays a part in #1078. Are we losing this info here?

[diegomarquezp]

Oh, we indeed need transport to be specified! I'll double check the impact of the other options.

[diegomarquezp]

So, the other option is rest_numeric_enums, which is used by HttpJsonServiceStubClassComposer to determine how to serialize enums (by number or value). I see that our spring composers do not mention enums, so it should be safe to remove.

[blakeli0]

It is probably not in scope now, but once SpringCodeGen decide to support both grpc and rest, we need a way to pass the correct value to this Spring specific bazel rule, and currently the only source of truth is the Bazel files in googleapis.

[blakeli0]

Two quick notes below. And a more general question for @blakeli0: about the resources jar processing portion in java_gapic_library here that Diego did not bring into spring rule: It seems to me it's only needed for client library to be used in java_gapic_pkg.bzl steps to produce a gapic-[package name]-java-resources.tar.gz with a build.gradle. IIUC that gradle file is not used in the post process of generating pom file, does it mean that all related logic can be potentially cleaned-up in gapic-generator itself in future?

The generated Gradle file are used by self-services client libraries(Ads, Geo etc.), so we are not going to remove them in the near term. However, we are trying to simplify the process by using the generator as a jar.

[sonarcloud]

SonarCloud Quality Gate failed.   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
2 Code Smells

0.0% Coverage
0.0% Duplication