google-cloud-java: test onboarding a new library

[zhumin8]

Onboard a new library via generate_new_client_hermetic_build.yaml.

To test library onboarding via librarian, in the same pull request created by above workflow,

• delete library code generated (this simulates a real new library addition for librarian, so pom.xml and other files that are only generated once are tested.)
• run librarian add
• librarian generate
• push the commit and verify diffs (expected diff: pom.xml comment markers added)

Alternatively, after a new library is added, use that commit to do same above.

Do this after migrate steps.
For context and blockers: go/sdk-librarian-migration-java

[zhumin8]

@sofisl This ends up to be very similar to #6033, I figure it would be more helpful to let you work it through with fresh eyes.
There is one (googleapis/google-cloud-java#13313) new API path added, a few more coming. Might be best to work on right before or after release is cut.

[sofisl]

Ok so after running my test with developers knowledge, here's what I found

1. I needed to add google/developers/knowledge/v1 to the sdk.yaml for the allowlist:

- path: google/developers/knowledge/v1
  languages:
    - java

2. The librarian add command added the following:

 - name: developers-knowledge
    version: 0.1.0-SNAPSHOT
    apis:
      - path: google/developers/knowledge/v1
    java:
      artifact_id: google-developers-knowledge

3. Afterwards I manually added the group_id to be able to generate the library:

      group_id: com.google.cloud

4. Then I ran:

librarian generate developers-knowledge

Since the developers-knowledge name (generated) is different from the name they actually went with developerknowledge, the whole library looks different. @zhumin8 should I start by investigating why this path looks so different? It's hard for me to tell what was manually edited by the Java team, and what is a librarian issue.

I'll post a separate comment for geminidataanalytics which looks a bit more straightforward.

[sofisl]

In my testing of geminidataanalytics, I had a lot more diffs, however there were less modifications I needed to make to get it to work (just running librarian add google/cloud/geminidataanalytics/v1 and librarian generate geminidataanalytics did the trick). However again I think these differences are due to the modifications in librarian.yaml, which is probably due to the differences in the migration script vs. the add logic.

[sofisl]

@zhumin8, should I be investigating why librarian add generates something so different from what the migration script does? That kind of makes sense to me, but then I'm not sure how to tackle these diffs.

[zhumin8]

re: developers knowledge

I needed to add google/developers/knowledge/v1 to the sdk.yaml for the allowlist

This step is not needed anymore. see #6165.
I am curious if you just did this step out of precautious or did you get an error? You might not be using the librarian version as listed in librarian.yaml

Since the developers-knowledge name (generated) is different from the name they actually went with developerknowledge,

This is a known difference: hermetic build guide suggests using api_short_name from service config, whereas librarian uses name derived from path. Read more context in doc and #6116.
For comparison sake manual change the code path to match so we can compare with git diff easier.

[zhumin8]

In my testing of geminidataanalytics, I had a lot more diffs, however there were less modifications I needed to make to get it to work (just running librarian add google/cloud/geminidataanalytics/v1 and librarian generate geminidataanalytics did the trick). However again I think these differences are due to the modifications in librarian.yaml, which is probably due to the differences in the migration script vs. the add logic.

This is the case that API path adds to an existing library. I forgot to mention to you that we are missing this step #6134 before it can generate correctly.
I believe in your test (without changes of migrate -insert-markers ., you should have seen an error in generate.

╰─$ go run github.com/googleapis/librarian/cmd/librarian@${V} generate geminidataanalytics
go: downloading github.com/googleapis/librarian v0.16.1-0.20260602193207-5917f20190fa
2026/06/03 10:17:27 librarian: generate library "geminidataanalytics" (java): failed to generate or update pom.xml files: failed to update client pom.xml google-cloud-geminidataanalytics: missing start marker "<!-- {x-generated-proto-dependencies-start} -->"
exit status 1

I did this test and showing diffs in https://github.com/googleapis/google-cloud-java/pull/13345/changes.
FYI - I will work on #6134 today.

[sofisl]

@zhumin8 I know what happened with developersknowledge and having to add it to sdk.yaml, I rewinded the library commit to before the library was generated so I could test cleanly. Instead what I did this time was pull from main, remove the entry for developersknowledge in librarian.yaml, and then ran add to re-add it. These are the diffs. Again, the biggest thing I see here is that there is a vast difference in the librarian.yaml which probably accounts for the diffs in the library. Should I investigate that, or is that expected?

Here are the steps I took this time:

1. The librarian add command added the following:

 - name: developers-knowledge
    version: 0.1.0-SNAPSHOT
    apis:
      - path: google/developers/knowledge/v1
    java:
      artifact_id: google-developers-knowledge
      group_id: change-it
      released_version: 0.0.0

2. Afterwards I manually added the group_id to be able to generate the library:

      group_id: com.google.cloud

3. Then I changed the name to more easily compare the diff:

 - name: developerknowledge

4. Then I generated the library.

librarian generate developers-knowledge

[zhumin8]

I think we are not comparing apples to apples here.
The code base has java-developerknowledge/google-cloud-developer-knowledge while your generated code java-developerknowledge/google-developers-knowledge.

It should be helpful to change artifact_id: google-cloud-developer-knowledge