feat: (Grounding) Initial client classes with generated API and model

[newtork]

Context

https://github.com/SAP/ai-sdk-java-backlog/issues/160

Generated model and API classes for grounding services.

Feature scope:

• generated grounding client (unreleased)
  • pipelines
  • vector
  • retrieval
• unit test

API for Grounding

The PR suggests the following API to interact with Grounding:

// Access client class
GroundingClient client = new GroundingClient();
GroundingClient client = new GroundingClient(new AiCoreService());

// Access generated API classes
PipelinesApi PIPELINES_API = client.pipelines();
VectorApi VECTOR_API = client.vecor();
RetrievalApi RETRIEVAL_API = client.retrieval();

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

[MatKuhr]

generally lgtm, I assume we do all the other release-relevant things once we actually set this to be released.

[MatKuhr]

LGTM so far 👍🏻

if we set this to released, we'd also need some minimal E2E test, sample code, docs & release note. Do you want to do this in a separate PR? (if so, maybe set this to unreleased for now so that we don't release it by accident 😉 )

For E2E tests / sample code, I'd consider at least a GET request. Maybe you can also copy the JS test where they cover creating and deleting a collection == repository. If so, please do that in the dedicated RG for Java.

[CharlesDuboisSAP]

When will we get data?

[newtork]

I created a backlog item for that.
JS colleagues also have no test yet.

https://github.com/SAP/ai-sdk-java-backlog/issues/202

[CharlesDuboisSAP]

When will this be tested?

[newtork]

It's tested as part of the big test suite testCreateDeleteCollection().

If you prefer, I'm okay with testing it as additional dedicated @Test case.

[CharlesDuboisSAP]

how does the unit testing work?

[newtork]

WireMock supports file-based stubbing

With that, you can define {"reqest: ": {...}, "response": {...}} in JSON format.
(+) less verbose JSON in unit test code
(-) payload decoupled from unit test cases

I wanted to see it in comparison with our other tests. We used the approach in Cloud SDK in some cases.
I'm fine with changing from this implicit to our regular explicit format, if requested.