You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Most tests require a running MarkLogic instance and deployed test resources.
Typical setup sequence:
docker compose up -d --build
./gradlew -i mlWaitTillReady
./gradlew -i mlDeploy
Run module tests
Override local MarkLogic connection settings via gradle-local.properties (mlHost, mlPassword).
Quality Controls
Treat compile warnings as failures: project builds enforce -Xlint:unchecked, -Xlint:deprecation, and -Werror.
Keep dependency security constraints intact (e.g. forced/excluded dependencies for CVE mitigation in Gradle files).
When adding or changing first-party Java/Kotlin code, run security scanning steps used by this workspace workflow before finalizing changes.
Do not relax quality gates (tests/compilation) to make a change pass; fix the underlying issue.
Code Generation And Automation
Data Services proxy generation is automated; use generateEndpointProxies instead of hand-writing proxy classes.
ml-development-tools test automation uses generateTests and fixMjsModulesForMarkLogic12 before test.
Generated sources commonly include an "IMPORTANT: Do not edit" header. Regenerate from source declarations instead of editing generated output directly.
For changes affecting generation logic, validate both generator behavior and generated artifact compilation/tests.
Conventions For Changes
Keep edits scoped to the target module; avoid cross-module churn unless required.
Prefer existing patterns in nearby code over introducing new abstractions.
For test-related fixes, document whether behavior changes impact unit tests, functional tests, or deployment setup.