Merge branch 'main' into mdwairi/fix-template-bug

Author: mdwairi

.release-please-manifest.json

@@ -1,7 +1,7 @@
 {
-  "expediagroup-sdk-core": "1.0.0",
-  "expediagroup-sdk-graphql": "1.0.0",
-  "expediagroup-sdk-rest": "1.0.0",
-  "expediagroup-sdk-openapi-plugin": "1.0.0",
-  "expediagroup-sdk-transport-okhttp": "1.0.0"
+  "expediagroup-sdk-core": "0.0.10-alpha",
+  "expediagroup-sdk-graphql": "0.0.8-alpha",
+  "expediagroup-sdk-rest": "0.0.13-alpha",
+  "expediagroup-sdk-openapi-plugin": "0.0.15-alpha",
+  "expediagroup-sdk-transport-okhttp": "0.0.6-alpha"
 }

build.gradle

@@ -4,7 +4,7 @@ import java.time.Duration
 
 plugins {
     id 'java'
-    id 'org.jetbrains.kotlin.jvm' version '2.1.10' apply false
+    id 'org.jetbrains.kotlin.jvm' version '2.2.0' apply false
     id "org.jlleitschuh.gradle.ktlint" version "12.1.2" apply false
     id 'org.jetbrains.kotlinx.kover' version "0.9.1" apply false
     id 'io.github.gradle-nexus.publish-plugin' version '2.0.0'

expediagroup-sdk-core/README.md

@@ -0,0 +1,128 @@
+[![Maven Central](https://img.shields.io/maven-central/v/com.expediagroup/expediagroup-sdk-core.svg)](https://search.maven.org/artifact/com.expediagroup/expediagroup-sdk-core)
+
+# Expedia Group JVM SDK - Core Module
+The `expediagroup-sdk-core` module serves as a reusable component that abstracts common functionalities, such as HTTP request execution, authentication, logging, and execution pipeline processing. It empowers product SDKs to focus on business-specific logic while ensuring consistency, flexibility, and maintainability.
+
+## Usage
+In most cases, you don’t need to add `expediagroup-sdk-core` directly, just include `expediagroup-sdk-rest` or `expediagroup-sdk-graphql` in your project, and the core module will be pulled in transitively.
+
+<details>
+  <summary><strong>Maven</strong></summary>
+
+  Add the `expediagroup-sdk-core` as a dependency in your `pom.xml`:
+
+  ```xml
+  <dependency>
+    <groupId>com.expediagroup</groupId>
+    <artifactId>expediagroup-sdk-core</artifactId>
+    <version>{latest-version}</version>
+  </dependency>
+  ```
+</details>
+
+
+<details>
+  <summary><strong>Gradle</strong></summary>
+
+  Add the `expediagroup-sdk-core` as a dependency in your `build.gradle`:
+
+  ```gradle
+  implementation 'com.expediagroup:expediagroup-sdk-core:{latest-version}'
+  ```
+</details>
+
+## Architecture & Components
+The SDK Core module serves as the foundational "shell" that abstracts the execution of requests and responses via an **injected** HTTP client. It acts as a toolkit, empowering product SDKs to deliver a polished and user-friendly experience by providing ready-to-use components such as request execution, logging, authentication, and exception handling. The SDK core streamlines the development of cohesive SDKs.
+
+### Transport Package
+The `Transport` interface defines the abstraction layer for making HTTP requests within the SDK. This interface allows SDK users to integrate their preferred HTTP client or transport mechanism while adhering to a standardized contract. The SDK relies on this interface to execute requests and process responses, offering flexibility and compatibility across diverse environments and libraries. To achieve complete abstraction, the SDK core module introduces standardized HTTP models customized for SDK usage (in the http package), such as `Request` and `Response`, which all `Transport` implementations are required to use. These models ensure consistency in how the SDK interacts with external systems, regardless of the underlying HTTP client or transport mechanism.
+
+> [!TIP]
+> Refer to SDK Transport Usage Guide for more information and examples
+
+### HTTP Package
+As mentioned earlier, the core module doesn’t depend on any specific HTTP client. To make this possible, the SDK defines its own generic HTTP request and response models. At runtime, those SDK models are translated into the native types required by your chosen HTTP client (for example, converting to OkHttp’s `Request` and `Response` objects).
+
+[http package](https://github.com/ExpediaGroup/expediagroup-java-sdk/tree/main/expediagroup-sdk-core/src/main/kotlin/com/expediagroup/sdk/core/http)
+
+### Pipeline Package
+While supporting injectable HTTP clients provides significant flexibility, it is essential to ensure that all requests made by the SDK adhere to governance and observability standards. This includes logging, authentication, client identification, and other critical processes, regardless of the underlying HTTP client being used. To achieve this, the core module introduces an `ExecutionPipeline`, which every product SDK must implement to integrate with the core.
+
+Each product SDK defines its own execution pipeline by composing "request pipeline **steps**" and "response pipeline **steps**". The core ensures that these steps are executed in the correct sequence: request steps are applied before the request is executed, and response steps are applied after the response is received.
+
+The primary entry point for integrating a product SDK with the core is through the `AbstractRequestExecutor` for synchronous calls and the `AbstractAsyncRequestExecutor` for asynchronous calls. These abstract classes enforce a consistent integration pattern by requiring implementers (i.e., product SDKs) to define the necessary `ExecutionPipeline`. This guarantees that governance and observability processes are applied consistently across all product SDKs, irrespective of the HTTP client used.
+
+[pipeline package](https://github.com/ExpediaGroup/expediagroup-java-sdk/tree/main/expediagroup-sdk-core/src/main/kotlin/com/expediagroup/sdk/core/pipeline)
+
+### Authentication Package
+The core module includes a suite of prebuilt components for handling common authentication schemes - such as Basic Auth & OAuth - so you don’t have to reinvent the wheel. True to the core’s “pluggable pipeline” philosophy, it provides the building blocks for each authentication workflow but leaves it up to the product SDK to decide when to invoke them.
+
+In practice, you simply add one of the supplied pipeline steps (for example, `BasicAuthStep` or `OAuthStep`) to your request execution pipeline. If your product SDK requires a custom authentication mechanism that isn’t yet provided, you can implement the `RequestPipelineStep` interface yourself, insert your new step into the pipeline, and encapsulate all of your custom auth logic there. This approach keeps authentication concerns isolated, consistent, and easy to extend.
+
+[auth package](https://github.com/ExpediaGroup/expediagroup-java-sdk/tree/main/expediagroup-sdk-core/src/main/kotlin/com/expediagroup/sdk/core/auth)
+
+### Logging Package
+All SDK modules rely on the `SLF4J` API for logging without shipping a concrete implementation, so you remain free to choose any `SLF4J` binding (such as Logback or Log4j2) at runtime. To turn on request and response logging, simply register the built-in `RequestLoggingStep` and `ResponseLoggingStep` in your execution pipeline; as long as you include a valid `SLF4J` binding on your classpath, those steps will automatically emit detailed logs for each outbound HTTP request and inbound HTTP response through your chosen logging framework.
+
+_A product SDK shouldn't provide the SLF4J implementation itself. This should be up to the end-user of the product SDK._
+
+Beyond basic request and response logging, the core module also lets you automatically redact any sensitive information - whether it lives in HTTP headers or in the body of a request or response - so that secrets never end up in your logs.
+
+[logging package](https://github.com/ExpediaGroup/expediagroup-java-sdk/tree/main/expediagroup-sdk-core/src/main/kotlin/com/expediagroup/sdk/core/logging)
+
+### Exception Package
+The SDK has a set of exception models each for a defined purpose, categorized based on the exception nature:
+- Client exception: Any exception that might be thrown or caused by the SDK itself (e.g. Configuration exception)
+- Service exception: Any exception that's caused by the remote server (e.g Authentication Exception).
+- All exceptions extend `ExpediaGroupException`.
+- All service exceptions extend `ExpediaGroupServiceException`.
+- All client exceptions extend `ExpediaGroupClientException`.
+
+[exception packagae](https://github.com/ExpediaGroup/expediagroup-java-sdk/tree/main/expediagroup-sdk-core/src/main/kotlin/com/expediagroup/sdk/core/exception)
+
+
+## Metadata Loader
+The core module includes a utility for loading runtime metadata such as SDK name, JVM version, SDK version, locale, etc... from `sdk.properties` file. Each product SDK must bundle this file in its resources, and it’s typically generated automatically during the build process.
+
+## Full Integration View - Diagram
+The diagram below illustrates the architecture and interaction between a product SDK and the SDK Core, highlighting the flow of operations and the role of various components in synchronous and asynchronous request execution.
+
+![Untitled-4](https://github.com/user-attachments/assets/65174c90-1881-4651-bef0-6554f00dab86)
+
+#### Operations & Models
+- Located at the far left, these represent the business-specific **operations** and models defined by the product SDK. These models will be typically **generated** by OpenAPI generator for REST SDKs, and from Apollo Kotlin for GraphQL SDKs.
+- These are entirely decoupled from the core module and are responsible for defining the domain-specific request and response structures.
+- The operations are converted into SDK requests, which are later executed via the core module.
+
+#### Sync Client
+- Represents the high-level client responsible for handling synchronous requests.
+- Converts an operation into a valid SDK request and sends it for execution.
+- Should encapsulate one implementation of `AbstractRequestExecutor` where this client can access the `execute` method along with the execution pipeline.
+- After receiving the response, the sync client converts the SDK response back into the corresponding operation response.
+
+#### Async Client
+- Represents the high-level client handling asynchronous requests.
+- Converts an operation into a valid SDK request and sends it for execution.
+- Should encapsulate one implementation of `AbstractAsyncRequestExecutor` where this client can access the `execute` method along with the execution pipeline.
+- Once the response is received (via a `CompletableFuture`), it is asynchronously converted into the corresponding operation response.
+
+#### Core Module:
+- SDK HTTP Models: Standardized Request and Response objects for consistent communication.
+- Authentication Module: Handles various authentication mechanisms.
+- Logging Module: Enables request/response logging for observability.
+- Metadata Loader: Loads extra runtime information about the SDK such as artifact name, version, Java version, and host OS.
+
+#### Execution Pipelines
+- Request Pipeline: Depicted with blue blocks, this pipeline processes the SDK request through a series of defined steps (e.g., adding headers, logging) before sending it to the transport layer.
+- Response Pipeline: Depicted with green blocks, this pipeline processes the SDK response through defined steps (e.g., logging) after it is received from the transport layer.
+
+#### Transport Layer
+- Sync Transport: Processes synchronous requests and returns a blocking response.
+- Async Transport: Processes asynchronous requests and returns a `CompletableFuture<Response>`.
+- By default, both `Transport` and `AsyncTransport` use the same HTTP client instance.
+
+
+
+
+
+

expediagroup-sdk-core/build.gradle

@@ -17,7 +17,7 @@ dependencies {
     api 'com.squareup.okio:okio:3.15.0'
 
     /* Serialization/Deserialization */
-    compileOnly(platform('com.fasterxml.jackson:jackson-bom:2.19.1'))
+    compileOnly(platform('com.fasterxml.jackson:jackson-bom:2.19.2'))
     compileOnly 'com.fasterxml.jackson.core:jackson-databind'
     compileOnly 'com.fasterxml.jackson.module:jackson-module-kotlin'
 
@@ -30,14 +30,14 @@ dependencies {
     testRuntimeOnly 'org.junit.jupiter:junit-jupiter-engine'
     testImplementation 'org.junit.jupiter:junit-jupiter-params'
 
-    testImplementation 'io.mockk:mockk:1.14.4'
+    testImplementation 'io.mockk:mockk:1.14.5'
     testImplementation 'com.squareup.okhttp3:mockwebserver:4.12.0'
 
     testImplementation 'org.slf4j:slf4j-api:2.0.17'
 
-    testImplementation(platform('com.fasterxml.jackson:jackson-bom:2.19.1'))
+    testImplementation(platform('com.fasterxml.jackson:jackson-bom:2.19.2'))
     testImplementation 'com.fasterxml.jackson.core:jackson-databind'
-    testImplementation 'com.fasterxml.jackson.module:jackson-module-kotlin:2.19.1'
+    testImplementation 'com.fasterxml.jackson.module:jackson-module-kotlin:2.19.2'
 }
 
 test {

expediagroup-sdk-graphql/README.md

@@ -0,0 +1,116 @@
+[![Maven Central](https://img.shields.io/maven-central/v/com.expediagroup/expediagroup-sdk-graphql.svg)](https://search.maven.org/artifact/com.expediagroup/expediagroup-sdk-graphql)
+
+# Expedia Group JVM SDK - GraphQL Module
+Building an SDK for GraphQL APIs presents unique challenges, such as defining the schema, constructing queries and mutations, and generating models. To address these requirements, this module was built as an extension package that adds GraphQL API support using Apollo Kotlin.
+
+Product SDKs that require GraphQL capabilities simply include this extension dependency, and Maven or Gradle will automatically pull in the core module transitively.
+
+## Installation
+
+_The `expediagroup-sdk-graphql` requires Java 8 or higher._
+
+<details>
+  <summary><strong>Maven</strong></summary>
+
+  Add the `expediagroup-sdk-graphql` as a dependency in your `pom.xml`:
+
+  ```xml
+  <dependency>
+    <groupId>com.expediagroup</groupId>
+    <artifactId>expediagroup-sdk-graphql</artifactId>
+    <version>{latest-version}</version>
+  </dependency>
+  ```
+</details>
+
+
+<details>
+  <summary><strong>Gradle</strong></summary>
+
+  Add the `expediagroup-sdk-graphql` as a dependency in your `build.gradle`:
+
+  ```gradle
+  implementation 'com.expediagroup:expediagroup-sdk-graphql:{latest-version}'
+  ```
+</details>
+
+## Architecture & Components
+The GraphQL module builds on the core abstractions to streamline GraphQL client setup and provides a compatibility layer that adapts Apollo Kotlin–generated operations to the core request/response pipeline with minimal configuration.
+
+### Apollo Kotlin Integration
+It's important to highlight that the GraphQL module depends only on the Apollo Kotlin API and its code-generation plugin and **not** on Apollo’s HTTP engine. This enables the SDK to work seamlessly with Apollo-generated operation classes and models while delegating all HTTP requests to its own transport layer. Meanwhile, Apollo remains responsible for serializing queries and deserializing responses, ensuring type-safe handling of the GraphQL payloads.
+
+### GraphQL Clients
+The GraphQL module provides a high-level abstract class, `GraphQLClient`, which serves as the integration point between your product SDK and the core SDK internals (executors, transports, etc.). 
+
+When you instantiate a `GraphQLClient`, you need to supply a `GraphQLExecutor` instance — a component responsible for orchestrating request execution and mapping errors to the SDK’s exception model. Under the hood, the `GraphQLExecutor` delegates to an `AbstractRequestExecutor` implementation from the core module, where you configure your request pipeline (authentication, logging, masking, etc.).
+
+```mermaid
+flowchart LR
+  GCI[MyGraphQLClient]
+  GC[GraphQLClient]
+  GE[GraphQLExecutor]
+  ARE[AbstractRequestExecutor]
+
+  %% relationships
+  GCI --> |extends| GC
+  GC --> |uses| GE
+  GE --> |uses| ARE
+```
+
+### GraphQL Responses Processing
+In GraphQL, API responses fall into four categories:
+| Response Type                 | Description                                                                          |
+|-------------------------------|--------------------------------------------------------------------------------------|
+| Successful response           | All requested data is returned.                                                      |
+| Partial response              | Some fields resolve successfully while others fail.                                  |
+| Error response (no data)      | The server processes the request but returns errors for every field, yielding no data. |
+| Exception response            | A transport or server error occurs, and no GraphQL payload is returned.              |
+
+
+Because GraphQL always uses an HTTP `2xx` status code, the SDK applies its own conventions in the `GraphQLExecutor` to make responses predictable:
+| Response Type                 | SDK Behavior                                                                                          |
+|-------------------------------|-------------------------------------------------------------------------------------------------------|
+| Exception response            | Throws an `ExpediaGroupServiceException`.                                                             |
+| Partial response              | Returns a `RawResponse` containing both the successfully resolved data and the error list.            |
+| Error response (no data)      | Throws a `NoDataException`, including the full response payload.                                      |
+| Successful response           | Returns a `RawResponse` with the data and an empty error list.                                        |
+
+  
+While similar to Apollo’s handling, this approach - especially throwing exceptions when no data is present — aligns with the broader SDK design and provides a consistent error‐handling model.
+
+### Pagination
+To simplify working with cursor or offset‐based GraphQL pagination, the SDK provides two abstract utilities:
+
+##### 1. PaginatedStream
+
+A lazy, sequential stream of items from any paginated data source.  
+
+**How it works**:  
+- Internally buffers one “page” of results at a time in a `Deque`.  
+- Calls your implementation of `fetchNextPage(): List<T>?` whenever the buffer is empty.  
+- Exposes a Java `Stream<T>` via `stream()`, so you can consume items one by one, without worrying about page boundaries.
+
+
+##### 2. Paginator
+A simple iterator‐style helper for paging through GraphQL responses that include both data and pageInfo in their model.
+
+**Responsibilities:**
+- Tracks whether more pages remain via your `hasPagesToFetch()` implementation.
+- Implements the `Iterator<T>` interface
+- `hasNext()` returns true until no further pages remain.
+- `next()` should be provided by your subclass to fetch each page’s `PaginatedResponse`.
+
+
+
+
+
+
+
+
+
+
+
+
+
+

expediagroup-sdk-graphql/build.gradle

@@ -28,7 +28,7 @@ dependencies {
     testImplementation 'org.junit.jupiter:junit-jupiter-api'
     testRuntimeOnly 'org.junit.jupiter:junit-jupiter-engine'
     testImplementation 'org.junit.jupiter:junit-jupiter-params'
-    testImplementation 'io.mockk:mockk:1.14.4'
+    testImplementation 'io.mockk:mockk:1.14.5'
     testImplementation 'com.squareup.okhttp3:mockwebserver:4.12.0'
     testImplementation 'org.slf4j:slf4j-api:2.0.17'
 }