DynamicLightEngine is a multi-module Maven project targeting Java/JDK 25:
engine-api: stable host/runtime boundary DTOs and contracts (org.dynamisengine.light.api)engine-spi: backend provider SPI and metadata (org.dynamisengine.light.spi)engine-impl-common: shared backend runtime lifecycle baseengine-impl-opengl: first runtime backend + ServiceLoader registrationengine-impl-vulkan: Vulkan backend skeleton + ServiceLoader registrationengine-bridge-dynamisfx: host bridge/mapping layer for DynamisFXengine-host-sample: minimal console host that discovers and runs a backend
Keep API and SPI JavaFX-agnostic. Backend-native objects must not cross engine-api.
Run from repository root:
mvn clean compile: compile all modulesmvn test: run tests across modulesmvn -pl engine-impl-opengl -am compile: build OpenGL backend and dependenciesmvn -pl engine-impl-vulkan -am compile: build Vulkan backend and dependenciesmvn -pl engine-api install: publish local snapshot of API modulemvn -DskipTests install && mvn -f engine-host-sample/pom.xml exec:java: run sample host loop
Use JDK 25 for normal development (maven.compiler.release=25 in root pom.xml).
Use 4-space indentation and UTF-8 source files. Prefer immutable records for DTOs and keep constructors defensive (List.copyOf, Map.copyOf, Set.copyOf).
- Classes/records/interfaces:
PascalCase - Methods/fields:
camelCase - Enums/constants:
UPPER_SNAKE_CASE - Package names: lowercase (
org.dynamisengine.light.*)
Respect lifecycle and threading contracts in runtime code: single engine thread, no callback reentrancy.
Place tests under each module at src/test/java. Mirror package structure and name tests by behavior (example: OpenGlEngineRuntimeLifecycleTest).
Minimum test coverage for new runtime features:
- lifecycle state transitions (
initialize,loadScene,render,shutdown) - invalid state/argument error paths (
EngineException,EngineErrorCode) - ServiceLoader backend discovery
Use Conventional Commits:
feat(api): add EngineCapabilities fieldfix(opengl): enforce initialize-before-rendertest(spi): add provider discovery tests
PRs must include:
- concise problem/solution summary
- linked issue or task ID
- verification notes with exact commands run
- logs/screenshots when runtime behavior changes are visible