chore: initial migration of spring generator code #1686
Conversation
From autoconfig-gen-draft2 branch, commit dcd082333eca7938e627855b294db995da06ee11
* Temporary assessment of scope of test-related code duplication * Has mvn test -DupdateUnitGoldens working in maven module setup
* Collapsed intermediate folder structure and relocated scripts * Addressed checkstyle issues enforced by repo and updated license header formats
* Adjusted scripts based on relative folder structure * Renaming of workspace, rules and files * Add release-please annotations
* Specify tool_java_runtime_version to Java 17 in bazel build * Remove java_gapic_pkg.bzl * Simplify scripts for googleapis build.bazel rule setups
This reverts commit 4674fd7.
emmileaf
changed the title
|
|
||
|
|
||
| # Spring generator | ||
| _spring_cloud_generator_version = "4.1.4-SNAPSHOT" # {x-version-update:spring-cloud-gcp:current} |
There was a problem hiding this comment.
I think this version needs to be in sync with the latest spring-cloud-gcp version? I'm actually not sure how it worked with the wrong version.
There was a problem hiding this comment.
You're right - thanks for catching this! I'm also confused to how this slipped past and kept working without the version being in sync - will take a look.
There was a problem hiding this comment.
Ah, this may have worked with the incorrect version because the setup here is redundant/unused in the generation process. I've trimmed away most of this file in 87df937, with a quick explanation below:
When initially following the gapic-generator-java approach, I was under the impression that the generator WORKSPACE needed a maven_install() for the end-to-end generation, and followed most of this setup.
On a second look at gapic-generator-java/WORKSPACE, I realize that it's fetching a snapshot jar, so probably just to allow for bazel invocations from within the repo (for integration tests?), while googleapis/WORKSPACE fetches a published version. In the spring codegen process, because we are not publishing the generator, the local copy of googleapis/WORKSPACE is already being modified with a maven_install() block to fetch the locally built generator as part of scripts. The version was correct there, which is why the generation workflow had worked.
This setup may be needed again when adding integration tests for the spring generator, but I will remove it for now given the additional version management.
| @@ -0,0 +1,146 @@ | |||
| # Copyright 2022 Google LLC | |||
There was a problem hiding this comment.
New files in this repo need to be have 2023 in the copyright header
There was a problem hiding this comment.
Also the copyright format is different from other files in this repo
There was a problem hiding this comment.
Per discussion - updated license header year to 2023 (eefaeb6) for migrated files that previously lived on branch, but not published to gapic-generator-java main.
* Not needed in generation workflow since it already modifies googleapis WORKSPACE with maven install of snapshot jar * gapic-generator-java setup uses this for running integration tests within the repo
|
Kudos, SonarCloud Quality Gate passed! |
5 participants
This PR contains an initial migration of generator code from
gapic-generator-java(see googleapis/sdk-platform-java#1580 for source) to thespring-cloud-gcprepo (alongside scripts and generated code).End-to-end workflow can be verified from this PR by creating a branch with libraries-bom version change and running:
For reviewers:
Please see #1686 (comment) for an outline of file roles (migrated content vs. original changes introduced by the migration), to help with navigating the PR diff.
High-level migration approach:
spring-cloud-generatoras a Bazel module (name:spring_cloud_generator, with BUILD.bazel and WORKSPACE)spring-cloud-generatoras a Maven submodule inspring-cloud-gcp(artifact name:com.google.api.spring-cloud-generator, with pom.xml)spring-cloud-gcp, and has dependency on publishedgapic-generator-javajarspring-cloud-previewsOther smaller changes:
library_list.txt, and added step in gh action to log contents after generating this file//=>/*) to align withspring-cloud-gcpchecksPlanned enhancements (not included in this PR):