Skip to content
Draft
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
23 changes: 23 additions & 0 deletions .cursor/rules/README.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,23 @@
# Cursor Rules – Contentstack Java CDA SDK

This directory contains Cursor AI rules that apply when working in this repository. Rules provide persistent context so the AI follows project conventions and Contentstack CDA patterns.

## How rules are applied

- **File-specific rules** use the `globs` frontmatter: they apply when you open or edit files matching that pattern.
- **Always-on rules** use `alwaysApply: true`: they are included in every conversation in this project.

## Rule index

| File | Applies when | Purpose |
|------|--------------|---------|
| **dev-workflow.md** | (Reference only; no glob) | Core development workflow: branches, running tests, PR expectations. Read for process guidance. |
| **java.mdc** | Editing any `**/*.java` file | Java 8 standards: naming, package layout, `com.contentstack.sdk` structure, logging, Lombok/annotations, avoiding raw types. |
| **contentstack-java-cda.mdc** | Editing `src/main/java/com/contentstack/sdk/**/*.java` | CDA-specific patterns: Stack/Config, host/version/region/branch, RetryOptions/RetryInterceptor, callbacks, alignment with Content Delivery API. |
| **testing.mdc** | Editing `src/test/**/*.java` | Testing patterns: JUnit 5, unit vs integration naming (`Test*` vs `*IT`), BaseIntegrationTest, timeouts, JaCoCo. |
| **code-review.mdc** | Always | PR/review checklist: API stability, error handling, backward compatibility, dependencies and security (e.g. SCA). |

## Related

- **AGENTS.md** (repo root) – Main entry point for AI agents: project overview, entry points, and pointers to rules and skills.
- **skills/** – Reusable skill docs (Contentstack Java CDA, testing, code review, framework) for deeper guidance on specific tasks.
36 changes: 36 additions & 0 deletions .cursor/rules/code-review.mdc
Original file line number Diff line number Diff line change
@@ -0,0 +1,36 @@
---
description: PR and code review checklist – API stability, errors, compatibility, security
alwaysApply: true
---

# Code Review Checklist – Contentstack Java CDA SDK

Use this checklist when reviewing pull requests or before opening a PR.

## API design and stability

- [ ] **Public API:** New or changed public methods/classes are necessary and clearly documented (Javadoc).
- [ ] **Backward compatibility:** No breaking changes to public API unless explicitly called out and justified (e.g. major version).
- [ ] **Naming:** Method and class names are consistent with existing SDK style and CDA terminology.

## Error handling and robustness

- [ ] **Errors:** API failures are mapped to the SDK **`Error`** type and passed through existing callback/result patterns.
- [ ] **Null safety:** No unintended NPEs; parameters and return values are documented or annotated where it matters (e.g. `@NotNull`/`@Nullable`).
- [ ] **Exceptions:** Checked exceptions are handled or declared; unchecked exceptions are used only where appropriate and documented.

## Dependencies and security

- [ ] **Dependencies:** No new dependencies without justification; version bumps are intentional and do not introduce known vulnerabilities.
- [ ] **SCA:** Address any security findings (e.g. from Snyk or similar) in the scope of the PR or in a follow-up.

## Testing

- [ ] **Coverage:** New or modified behavior is covered by unit and/or integration tests as appropriate.
- [ ] **Test quality:** Tests are readable, stable (no flakiness), and follow project conventions (`Test*` / `*IT`, `BaseIntegrationTest` for integration tests).

## Severity (optional)

- **Blocker:** Must fix before merge (e.g. breaking public API without approval, security issue, no tests for new code).
- **Major:** Should fix (e.g. inconsistent error handling, missing Javadoc on new public API).
- **Minor:** Nice to fix (e.g. style, minor docs).
35 changes: 35 additions & 0 deletions .cursor/rules/contentstack-java-cda.mdc
Original file line number Diff line number Diff line change
@@ -0,0 +1,35 @@
---
description: Contentstack CDA patterns – Stack/Config, HTTP, retry, callbacks, Content Delivery API
globs: "src/main/java/com/contentstack/sdk/**/*.java"
---

# Contentstack Java CDA – SDK Rules

Apply when editing the SDK core (`com.contentstack.sdk`). Keep behavior aligned with the [Content Delivery API](https://www.contentstack.com/docs/apis/content-delivery-api/).

## Stack and Config

- **Entry point:** `Contentstack.stack(apiKey, deliveryToken, environment)` returns a `Stack`. Use `Config` for optional settings.
- **Default host:** `cdn.contentstack.io`; **API version:** `v3` (see `Config`).
- **Config options:** host, version, scheme, region (`ContentstackRegion`), branch, live preview, proxy, connection pool, **RetryOptions**, early access, plugins. Set these via `Config` before building the stack.
- **Region/branch:** Support `Config.setRegion()` and `Config.setBranch()` for regional and branch-specific delivery.

## HTTP layer

- **Requests** go through **`CSHttpConnection`** and **`APIService`** (Retrofit). Do not bypass this for CDA calls.
- **Headers:** Use the same headers and User-Agent as the rest of the SDK (see `Constants` and request setup in `CSHttpConnection`).
- **Errors:** Map API errors to the SDK **`Error`** class (errorMessage, errorCode, errDetails) and pass to **`ResultCallBack`** or equivalent callback.

## Retry and resilience

- **RetryOptions:** Configurable retry limit, delay, backoff strategy (e.g. exponential), and retryable status codes (e.g. 408, 429, 502, 503, 504). Defaults are in `RetryOptions`.
- **RetryInterceptor:** Uses `RetryOptions` to retry failed HTTP requests. Keep retry behavior consistent when changing the HTTP client or interceptors.

## Callbacks and async

- Use existing callback types (e.g. **`ResultCallBack`**, **`EntryResultCallBack`**, **`QueryResultsCallBack`**) for async results. Do not introduce incompatible callback signatures without considering backward compatibility.
- Pass **`Error`** and response data through the same callback patterns used elsewhere in the SDK.

## CDA concepts

- **Entry,** **Query,** **Asset,** **Content Type,** **Sync,** **Taxonomy** – follow existing class and method names and the CDA API semantics (e.g. query params, response parsing). When adding new CDA features, align with the official Content Delivery API documentation.
27 changes: 27 additions & 0 deletions .cursor/rules/dev-workflow.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,27 @@
# Development Workflow – Contentstack Java CDA SDK

Use this as the standard workflow when contributing to the Java CDA SDK.

## Branches

- Use feature branches for changes (e.g. `feat/...`, `fix/...`).
- Base work off the appropriate long-lived branch (e.g. `staging`, `development`) per team norms.

## Running tests

- **All tests:** `mvn test`
- **Specific test class:** `mvn test -Dtest=TestEntry`
- **Integration tests only:** `mvn test -Dtest='*IT'`
- **Unit tests only:** `mvn test -Dtest='Test*'`

Run tests before opening a PR. Integration tests may require a valid `.env` with stack credentials (see `Credentials` and `BaseIntegrationTest` in the test suite).

## Pull requests

- Ensure the build passes: `mvn clean test`
- Follow the **code-review** rule (see `.cursor/rules/code-review.mdc`) for the PR checklist.
- Keep changes backward-compatible for public API; call out any breaking changes clearly.

## Optional: TDD

If the team uses TDD, follow RED–GREEN–REFACTOR when adding behavior: write a failing test first, then implement to pass, then refactor. The **testing** rule and **skills/testing** skill describe test structure and naming.
41 changes: 41 additions & 0 deletions .cursor/rules/java.mdc
Original file line number Diff line number Diff line change
@@ -0,0 +1,41 @@
---
description: Java 8 standards and com.contentstack.sdk conventions for the CDA SDK
globs: "**/*.java"
---

# Java Standards – Contentstack Java CDA SDK

Apply these conventions when editing Java code in this repository.

## Language and runtime

- **Java 8** (source/target 1.8). Do not use language or API features that require a higher version.
- Avoid raw types; use proper generics where applicable.

## Package and layout

- All SDK code lives under **`com.contentstack.sdk`** (see `src/main/java/com/contentstack/sdk/`).
- Keep the existing package structure; do not introduce new top-level packages without alignment with the rest of the SDK.

## Naming

- **Classes:** PascalCase (e.g. `CSHttpConnection`, `RetryOptions`).
- **Methods/variables:** camelCase.
- **Constants:** UPPER_SNAKE_CASE (e.g. in `Constants.java`).
- **Test classes:** `Test*` for unit tests, `*IT` for integration tests (see **testing.mdc** for test rules).

## Logging

- Use **`java.util.logging`** (Logger) as in `CSHttpConnection` and other SDK classes.
- Obtain loggers with `Logger.getLogger(ClassName.class.getName())`.
- Log at appropriate levels (e.g. `warning` for recoverable issues, `fine`/`finer` for debug).

## Annotations and Lombok

- Use **Lombok** where the project already does (e.g. getters/setters, builders) for consistency.
- Use **`@NotNull`** / **`@Nullable`** (e.g. JetBrains annotations) where they are already used to document nullability.

## General

- Prefer immutability where practical (e.g. final fields, defensive copies for collections).
- Document public API with Javadoc; keep examples in Javadoc in sync with actual usage (e.g. `Contentstack.stack(...)`, `Config`).
35 changes: 35 additions & 0 deletions .cursor/rules/testing.mdc
Original file line number Diff line number Diff line change
@@ -0,0 +1,35 @@
---
description: JUnit 5 testing patterns, unit vs integration, BaseIntegrationTest, JaCoCo
globs: "src/test/**/*.java"
---

# Testing Rules – Contentstack Java CDA SDK

Apply when writing or editing tests. The project uses **JUnit 5** and **JaCoCo** (see `pom.xml`).

## Test naming and layout

- **Unit tests:** Class name prefix **`Test`** (e.g. `TestEntry`, `TestConfig`). Place in `src/test/java/com/contentstack/sdk/`.
- **Integration tests:** Class name suffix **`IT`** (e.g. `ContentstackIT`, `SyncStackIT`). Same package. Use **`BaseIntegrationTest`** for shared setup and timeouts.

## JUnit 5 usage

- Use **JUnit 5** (Jupiter) APIs: `@Test`, `@BeforeAll`, `@AfterAll`, `@BeforeEach`, `@AfterEach`, `@DisplayName`, etc.
- Prefer **`TestInstance(Lifecycle.PER_CLASS)`** when sharing a single instance across tests (e.g. `BaseIntegrationTest`).
- Use **assertions** from `org.junit.jupiter.api.Assertions`.

## Integration test base and timeouts

- Extend **`BaseIntegrationTest`** for integration tests that need a real stack. It provides:
- `stack` from **`Credentials.getStack()`** (`.env`-based).
- Timeout constants: `DEFAULT_TIMEOUT_SECONDS`, `PERFORMANCE_TIMEOUT_SECONDS`, `LARGE_DATASET_TIMEOUT_SECONDS`.
- Use **`Assertions.assertTimeout(Duration.ofSeconds(...), () -> { ... })`** (or equivalent) for async or long-running operations so tests don’t hang.

## Test data and credentials

- **Credentials:** Use **`Credentials`** and a `.env` file for integration tests (API key, delivery token, environment). Do not commit real tokens; document required env vars (e.g. in README or test docs).
- **Fixtures:** Use existing test assets (e.g. under `src/test/` or `target/test-classes/`) where applicable.

## Coverage

- **JaCoCo** is configured in `pom.xml`. Reports are generated on `mvn test` (e.g. `target/site/jacoco/`). Maintain or improve coverage when adding or changing production code; avoid removing tests that cover critical paths without replacement.
50 changes: 50 additions & 0 deletions AGENTS.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,50 @@
# Contentstack Java CDA SDK – Agent Guide

This document is the main entry point for AI agents working in this repository.

## Project

- **Name:** Contentstack Java CDA SDK (contentstack-java)
- **Purpose:** Java client for the Contentstack **Content Delivery API (CDA)**. It fetches content (entries, assets, content types, sync, taxonomy) from Contentstack and delivers it to Java applications.
- **Repo:** [contentstack-java](https://github.com/contentstack/contentstack-java)

## Tech stack

- **Language:** Java 8 (source/target 1.8)
- **Build:** Maven
- **Testing:** JUnit 5, JaCoCo (coverage)
- **HTTP:** Retrofit 2, OkHttp
- **Other:** Gson, RxJava 3, Lombok, contentstack-utils

## Main entry points

- **`Contentstack`** – Static factory: `Contentstack.stack(apiKey, deliveryToken, environment)` returns a `Stack`.
- **`Stack`** – Main API surface: entries, assets, content types, sync, live preview, etc.
- **`Config`** – Optional configuration: host, version, region, branch, retry, proxy, connection pool, plugins.
- **Paths:** `src/main/java/com/contentstack/sdk/` (production), `src/test/java/com/contentstack/sdk/` (tests).

## Commands

- **Build and test:** `mvn clean test`
- **Single test class:** `mvn test -Dtest=TestEntry`
- **Integration tests only:** `mvn test -Dtest='*IT'`
- **Unit tests only:** `mvn test -Dtest='Test*'`

Integration tests may require a `.env` with stack credentials (see `Credentials` and test README/docs).

## Rules and skills

- **`.cursor/rules/`** – Cursor rules for this repo:
- **README.md** – Index of all rules.
- **dev-workflow.md** – Development workflow (branches, tests, PRs).
- **java.mdc** – Applies to `**/*.java`: Java 8 and SDK conventions.
- **contentstack-java-cda.mdc** – Applies to SDK core: CDA patterns, Config, HTTP, retry, callbacks.
- **testing.mdc** – Applies to `src/test/**/*.java`: JUnit 5, Test* / *IT, BaseIntegrationTest, JaCoCo.
- **code-review.mdc** – Always applied: PR/review checklist.
- **`skills/`** – Reusable skill docs:
- Use **contentstack-java-cda** when implementing or changing CDA API usage or SDK core behavior.
- Use **testing** when adding or refactoring tests.
- Use **code-review** when reviewing PRs or before opening one.
- Use **framework** when changing config, retry, or HTTP layer (Config, RetryOptions, RetryInterceptor, CSHttpConnection).

Refer to `.cursor/rules/README.md` for when each rule applies and to `skills/README.md` for skill details.
6 changes: 3 additions & 3 deletions pom.xml
Original file line number Diff line number Diff line change
Expand Up @@ -181,17 +181,17 @@
<dependency>
<groupId>com.fasterxml.jackson.core</groupId>
<artifactId>jackson-databind</artifactId>
<version>2.21.0</version>
<version>2.21.1</version>
</dependency>
<dependency>
<groupId>com.slack.api</groupId>
<artifactId>bolt</artifactId>
<version>1.46.0</version>
<version>1.47.0</version>
</dependency>
<dependency>
<groupId>org.jetbrains</groupId>
<artifactId>annotations</artifactId>
<version>26.0.2</version>
<version>26.1.0</version>
</dependency>
<dependency>
<groupId>com.squareup.okhttp3</groupId>
Expand Down
21 changes: 21 additions & 0 deletions skills/README.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,21 @@
# Skills – Contentstack Java CDA SDK

This directory contains **skills**: reusable guidance for AI agents (and developers) on specific tasks. Each skill is a folder with a `SKILL.md` file.

## When to use which skill

| Skill | Use when |
|-------|----------|
| **contentstack-java-cda** | Implementing or changing CDA features: Stack/Config, entries, assets, content types, sync, taxonomy, HTTP layer, retry, callbacks, error handling. |
| **testing** | Writing or refactoring tests: JUnit 5, unit vs integration layout, BaseIntegrationTest, timeouts, Credentials/.env, JaCoCo. |
| **code-review** | Reviewing a PR or preparing your own: API design, null-safety, exceptions, backward compatibility, dependencies/security, test coverage. |
| **framework** | Touching config, retry, or the HTTP layer: Config options, RetryOptions/RetryInterceptor, CSHttpConnection, connection/request flow, error handling. |

## How agents should use skills

- **contentstack-java-cda:** Apply when editing SDK core (`com.contentstack.sdk`) or adding CDA-related behavior. Follow Stack/Config, CDA API alignment, and existing callback/error patterns.
- **testing:** Apply when creating or modifying test classes. Follow naming (`Test*` / `*IT`), BaseIntegrationTest for integration tests, and existing Surefire/JaCoCo setup.
- **code-review:** Apply when performing or simulating a PR review. Go through the checklist (API stability, errors, compatibility, dependencies, tests) and optional severity levels.
- **framework:** Apply when changing Config, RetryOptions, RetryInterceptor, or CSHttpConnection. Keep retry and connection behavior consistent with the rest of the SDK.

Each skill’s `SKILL.md` contains more detailed instructions and references.
60 changes: 60 additions & 0 deletions skills/code-review/SKILL.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,60 @@
---
name: code-review
description: Use when reviewing PRs or before opening a PR – API design, null-safety, exceptions, backward compatibility, dependencies, security, and test quality
---

# Code Review – Contentstack Java CDA SDK

Use this skill when performing or preparing a pull request review for the Java CDA SDK.

## When to use

- Reviewing someone else’s PR.
- Self-reviewing your own PR before submission.
- Checking that changes meet project standards (API, errors, compatibility, tests, security).

## Instructions

Work through the checklist below. Optionally tag items with severity: **Blocker**, **Major**, **Minor**.

### 1. API design and stability

- [ ] **Public API:** New or changed public methods/classes are necessary and documented (Javadoc with purpose and, where relevant, params/returns).
- [ ] **Backward compatibility:** No breaking changes to public API unless explicitly agreed (e.g. major version). Deprecations should have alternatives and timeline.
- [ ] **Naming:** Consistent with existing SDK style and CDA terminology (e.g. `Stack`, `Entry`, `Query`, `Config`).

**Severity:** Breaking public API without approval = Blocker. Missing docs on new public API = Major.

### 2. Error handling and robustness

- [ ] **Errors:** API failures are mapped to the SDK `Error` type and passed through existing callback/result patterns (e.g. `ResultCallBack`).
- [ ] **Null safety:** No unintended NPEs; document or annotate (e.g. `@NotNull`/`@Nullable`) where it matters for public API.
- [ ] **Exceptions:** Checked exceptions are handled or declared; use of unchecked exceptions is intentional and documented where relevant.

**Severity:** Wrong or missing error handling in new code = Major.

### 3. Dependencies and security

- [ ] **Dependencies:** New or upgraded dependencies are justified. Version bumps are intentional and do not introduce known vulnerabilities.
- [ ] **SCA:** Any security findings (e.g. Snyk, Dependabot) in the change set are addressed or explicitly deferred with a ticket.

**Severity:** New critical/high vulnerability = Blocker.

### 4. Testing

- [ ] **Coverage:** New or modified behavior has corresponding unit and/or integration tests.
- [ ] **Conventions:** Tests follow naming (`Test*` unit, `*IT` integration) and use `BaseIntegrationTest` for integration tests where appropriate.
- [ ] **Quality:** Tests are readable, deterministic (no flakiness), and assert meaningful behavior.

**Severity:** No tests for new behavior = Blocker. Flaky or weak tests = Major.

### 5. Optional severity summary

- **Blocker:** Must fix before merge (e.g. breaking API without approval, security issue, no tests for new code).
- **Major:** Should fix (e.g. inconsistent error handling, missing Javadoc on new public API, flaky tests).
- **Minor:** Nice to fix (e.g. style, minor docs, redundant code).

## References

- Project rule: `.cursor/rules/code-review.mdc`
- Testing skill: `skills/testing/SKILL.md` for test standards
Loading
Loading