بنقرة واحدة
judo-backend-docs
// Backend development guide for JUDO applications. Covers custom operations, interceptors, validators, data access, and error handling.
// Backend development guide for JUDO applications. Covers custom operations, interceptors, validators, data access, and error handling.
ESM-to-UI mapping reference for JUDO React frontends. Covers widget mappings, table and navigation element mappings, and the ESM→UI transformation model.
Frontend development guide for JUDO React applications. Covers hooks, theming, i18n, and Pandino DI customization patterns.
ESM metamodel reference for JUDO. Covers namespace, type, structure, operation, accesspoint, UI, UI-behaviour, and UI-visual-styleguide packages with element-level attribute and constraint definitions.
Model documentation for JUDO applications. Covers ESM metamodel, cardinality, CRUD flags, and advanced modeling patterns.
Deployment and build documentation for JUDO applications. Covers judo.sh commands, Docker setup, Karaf configuration, and production deployment.
E2E testing guide for JUDO React frontends using Playwright. Covers test patterns, helpers, and browser automation.
| name | judo-backend-docs |
| description | Backend development guide for JUDO applications. Covers custom operations, interceptors, validators, data access, and error handling. |
| disable-model-invocation | false |
| user-invocable | false |
| agent | general-purpose |
Backend development in northwind involves implementing custom business logic in Java while leveraging the JUDO-generated SDK and runtime infrastructure.
Note: Throughout this document, northwind refers to the application name from judo.properties (app_name property). Package names, file paths, and generated artifacts use this value.
application/app/, application/interceptors/). These areas are protected from the code generation process.Generated (Do Not Edit Directly):
application/sdk/)application/internal/)application/rest/)Custom Implementation (Edit Here):
application/app/)application/interceptors/)How Generation Works:
.generated-files (located in generator output directories).generator-ignore will be regenerated on ./judo.sh build or ./judo.sh generateWhen You Must Edit Generated Files:
Before editing a generated file directly, check the two extension mechanisms offered by the template — they keep the file under generator control and survive future template upgrades:
generator-parameter.properties (see deployment/build-process.md → When to Check Templates Instead of Patching).pom.xml, feature.xml, and similar files expose named fragments you can fill in by dropping a file under application/generator-overrides/<fragment-path>. Look for paired marker comments such as
<!-- To define create 'app/pom.xml.extra-dependencies.fragment.hbs' file -->
<!-- End of 'app/pom.xml.extra-dependencies.fragment.hbs' -->
See deployment/build-process.md → Extending Generated Files via Fragment Overrides for the full list and a worked example.Only if neither mechanism offers a hook should you fall back to editing the generated file directly. This is NOT the preferred way, but when necessary:
.generator-ignore to protect it from regeneration
echo "application/sdk/src/main/java/[PACKAGE]/[GeneratedFile].java" >> .generator-ignore
.generator-ignore near related overrides (it's used like .gitignore)Handling Checksum Errors:
If you get checksum errors due to code formatting changes (e.g., after git checkout or IDE auto-format in dev mode):
# Ignore checksum errors and force regeneration
./judo.sh generate -i
# or
./judo.sh build -i
Checksum File Locations:
.generated-files - In each generator output directoryThis project uses SDKMAN for version management. Required versions are specified in .sdkmanrc:
java=21.0.7-zulu
maven=3.9.10
mvnd=1.0.2
Setup:
# 1. Install SDKMAN (if not already installed)
curl -s "https://get.sdkman.io" | bash
source "$HOME/.sdkman/bin/sdkman-init.sh"
# 2. Enable auto-env (recommended - automatic version switching)
echo "sdkman_auto_env=true" >> ~/.sdkman/etc/config
# 3. Install versions from .sdkmanrc
cd [project-name]
sdk env install
# 4. Verify
java -version # Should show 21.0.7-zulu
mvn -version # Should show 3.9.10
How It Works:
.sdkmanrc is generated by ./judo.sh generate-root commandsdkman_auto_env=true, SDKMAN automatically switches to project versions when you enter the directory./judo.sh script automatically installs required versions if missingMaven Daemon (mvnd): Optional but recommended for faster builds
# Use mvnd instead of mvn for faster incremental builds
mvnd clean install
application/
├── sdk/ # Generated API interfaces
│ └── src/main/java/[PACKAGE]/
│ └── [Entity]Dao.java, [Entity]Service.java
├── internal/ # Generated SDK wrappers (binds custom to runtime)
├── app/ # ✏️ CUSTOM OPERATIONS HERE
│ └── src/main/java/[PACKAGE]/
│ └── Custom[Entity]ServiceImpl.java
├── interceptors/ # ✏️ CUSTOM INTERCEPTORS HERE
│ └── src/main/java/[PACKAGE]/
│ ├── LogAuthenticationInterceptor.java
│ └── LogOperationCallInterceptor.java
└── rest/ # Generated JAX-RS endpoints
└── resources/
Note: Package structure is generated from the model and typically follows patterns like hu.blackbelt.model.northwind or party.mkkp.northwind.
judo-integration-testing-docs skill) - Testing custom operations with judo-runtime-core-testkit.