|
| 1 | +# Project Guidelines |
| 2 | + |
| 3 | +## Architecture |
| 4 | +- `marklogic-client-api`: core Java client library for interacting with the MarkLogic REST API. |
| 5 | +- `ml-development-tools`: Gradle plugin and generators for Data Services endpoint proxies/tests. |
| 6 | +- `marklogic-client-api-functionaltests`: functional/regression-style tests, split into fragile/fast/slow groups. |
| 7 | +- `test-app`: ml-gradle deployment project that provisions test infrastructure in MarkLogic. |
| 8 | +- `examples`: supporting code used by tests and usage examples. |
| 9 | + |
| 10 | +## Build And Test |
| 11 | +- Prefer Gradle from the repo root. |
| 12 | +- Quick compile verification: `./gradlew clean build -x test` |
| 13 | +- Core module tests: `./gradlew marklogic-client-api:test` |
| 14 | +- Plugin tests (includes generated tests workflow): `./gradlew ml-development-tools:test` |
| 15 | +- Functional tests must run in this order to reduce flakiness: |
| 16 | + 1. `./gradlew marklogic-client-api-functionaltests:runFragileTests` |
| 17 | + 2. `./gradlew marklogic-client-api-functionaltests:runFastFunctionalTests` |
| 18 | + 3. `./gradlew marklogic-client-api-functionaltests:runSlowFunctionalTests` |
| 19 | + |
| 20 | +## Test Environment |
| 21 | +- Java 17+ is required for current releases. |
| 22 | +- Most tests require a running MarkLogic instance and deployed test resources. |
| 23 | +- Typical setup sequence: |
| 24 | + 1. `docker compose up -d --build` |
| 25 | + 2. `./gradlew -i mlWaitTillReady` |
| 26 | + 3. `./gradlew -i mlDeploy` |
| 27 | + 4. Run module tests |
| 28 | +- Override local MarkLogic connection settings via `gradle-local.properties` (`mlHost`, `mlPassword`). |
| 29 | + |
| 30 | +## Quality Controls |
| 31 | +- Treat compile warnings as failures: project builds enforce `-Xlint:unchecked`, `-Xlint:deprecation`, and `-Werror`. |
| 32 | +- Keep dependency security constraints intact (e.g. forced/excluded dependencies for CVE mitigation in Gradle files). |
| 33 | +- When adding or changing first-party Java/Kotlin code, run security scanning steps used by this workspace workflow before finalizing changes. |
| 34 | +- Do not relax quality gates (tests/compilation) to make a change pass; fix the underlying issue. |
| 35 | + |
| 36 | +## Code Generation And Automation |
| 37 | +- Data Services proxy generation is automated; use `generateEndpointProxies` instead of hand-writing proxy classes. |
| 38 | +- `ml-development-tools` test automation uses `generateTests` and `fixMjsModulesForMarkLogic12` before `test`. |
| 39 | +- Generated sources commonly include an "IMPORTANT: Do not edit" header. Regenerate from source declarations instead of editing generated output directly. |
| 40 | +- For changes affecting generation logic, validate both generator behavior and generated artifact compilation/tests. |
| 41 | + |
| 42 | +## Conventions For Changes |
| 43 | +- Keep edits scoped to the target module; avoid cross-module churn unless required. |
| 44 | +- Prefer existing patterns in nearby code over introducing new abstractions. |
| 45 | +- For test-related fixes, document whether behavior changes impact unit tests, functional tests, or deployment setup. |
| 46 | + |
| 47 | +## Docs To Link (Do Not Duplicate) |
| 48 | +- `README.md`: product overview, dependency usage, Java compatibility. |
| 49 | +- `CONTRIBUTING.md`: local build/test workflow and MarkLogic test setup. |
| 50 | +- `ml-development-tools/src/test/example-project/README.md`: plugin-focused usage/testing notes. |
0 commit comments