fix: request #673

[jazzm0]

Context

feat: retrieve chunks with search.

AI/ai-sdk-java-backlog#673

This will fix issue #673 for convenience

Feature scope:

• Task1
• Task2
  • SubTask1

Definition of Done

• Functionality scope stated & covered
• Tests cover the scope above
• Error handling created / updated & covered by the tests above
• Aligned changes with the JavaScript SDK
• Documentation updated
• Release notes updated

[cla-assistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[newtork]

Thanks for the contribution! And it does make sense on first sight.
Unfortunately we cannot merge this, since the original code is generated. And it will remain generated for future service changes.

Once we decide to manually adjust generated code (like here) we would find ourself in responsibility to maintain and support it over long time. This is not a commitment we can take as team without management approval at the moment.

[jazzm0]

Thanks for the contribution! And it does make sense on first sight. Unfortunately we cannot merge this, since the original code is generated. And it will remain generated for future service changes.

Once we decide to manually adjust generated code (like here) we would find ourself in responsibility to maintain and support it over long time. This is not a commitment we can take as team without management approval at the moment.

Hello,
Thank you for your response and for explaining the reasoning behind not merging the contribution. I understand the challenges involved in maintaining manually adjusted generated code over time.
Out of curiosity, could you share what tool or system you're using to generate the code? I'm wondering if there's a built-in way to incorporate customizations during the generation process. Additionally, I wanted to kindly note that it might pose some difficulties for API consumers if they need to implement workarounds due to the generated nature of the code—perhaps there's an alternative approach we could explore to address this?
I appreciate your time and any further insights you can provide.

Kind Regards

[jazzm0]

One fix could be to extend the API classes, therefore separating the generated class from the extension.

[rpanackal]

could you share what tool or system you're using to generate the code?

We use the Cloud SDK OpenAPI generator. You can find related documentation here. This is our wrapper around the OpenAPI generator.

One fix could be to extend the API classes, therefore separating the generated class from the extension.

The *Api.java classes are also part of the generated code. Since generated code is considered unstable, extending it may not be the best option forward. Generally, we write the wrapper classes that are more stable (shielding) and convenient as visible in the orchestration and openai modules. The same support is not yet offered for Grounding Service and require approval from the management (on our side).

Your interest and effort is appreciated and strengthens the case first-class grounding module support.

[Jonas-Isr]

Closing this PR since changing generated code is not an option. We are also not going to implement a convenience layer for the grounding client at the moment.