Chenile Repository Guides

Edit me

chenile-parent

Role:

• Super-parent POM for the Chenile ecosystem
• Aligns framework-wide dependency versions, plugin versions, Java version, and release properties

Why it matters:

• Every other primary Chenile repository inherits from it.
• Release sequencing starts here.

chenile-core

Role:

• Runtime foundation of Chenile

Modules:

• stm
• chenile-base
• owiz
• chenile-core
• chenile-http
• cucumber-utils
• utils
• jpa-utils
• multi-datasource-utils
• chenile-mcp

Context note:

• chenile-core owns ContextContainer, the request-scoped thread-local metadata holder used by interceptors, tenant routing, ID generation, and related helpers.
• It is safe for synchronous same-thread request handling, but it should not be relied on for implicit async or reactive context propagation.
• The core tests include an executor-based isolation test proving that two concurrent requests do not leak ContextContainer headers into each other when each request stays on its own thread.

Version note:

• chenile-core now aggregates every classpath *version.txt resource into a runtime version map.
• Services can declare serviceModule and resolve their service version from a named xxx.version entry rather than only from the default service id mapping.
• /info exposes the aggregated version map.
• getVersion("xxx") resolves xxx.version, which makes multi-family versioning practical inside one running monolith.
• serviceModule is optional in both service JSON and @ChenileController, and defaults from the service id when omitted.
• versionProperty remains available as a deprecated compatibility alias.
• This lets framework-level services resolve from keys such as chenile.version, while platform or application service families can resolve from their own shared version keys.

Admin UI note:

• chenile-core now includes chenile-admin-ui, a standalone React frontend for inspecting running Chenile monoliths.
• It supports both local service inspection through /info and /service-info/{service}, and ecosystem-wide inspection through GET /serviceregistry when the target monolith hosts serviceregistryService.

chenile-query-workflow-blueprints

Role:

• Main higher-level blueprint repository above chenile-core

Modules:

• query-api
• chenile-query-service
• chenile-query-controller
• workflow-api
• workflow-service
• cucumber-workflow-utils
• workflow-utils
• stm-generate-puml

chenile-service-registry

Role:

• Registry layer for service discovery, lookup, and delegate-style interaction support

Modules:

• service-registry-api
• service-registry-service
• service-registry-delegate

chenile-proxies

Role:

• Interface-based proxying for Chenile services

Modules:

• chenile-proxy

chenile-security

Role:

• Chenile security stack: API contracts, runtime support, interceptors, and test helpers

Modules:

• chenile-security
• chenile-security-api
• cucumber-sec-utils
• security-interceptor

chenile-messaging

Role:

• Messaging and pub-sub integrations across multiple transports

Modules:

• chenile-pub-sub
• cucumber-mqtt-utils
• chenile-mqtt
• cloud-edge-switch
• chenile-kafka
• chenile-azure
• chenile-jvm-pub-sub

chenile-bdd

Role:

• BDD and integration-test support modules

Modules:

• it-cucumber-utils
• it-cucumber-sec-utils

chenile-others

Role:

• Auxiliary entry points and supporting integrations

Modules:

• chenile-filewatch
• chenile-scheduler
• chenile-cache
• chenile-config-maven-plugin

chenile-process-management

Role:

• Long-running parent and child process orchestration

Modules:

• process-api
• process-service
• process-delegate
• process-utils
• q-based-process-starter
• invm-process-starter

cconfig

Role:

• Modular configuration system for Chenile applications

Modules:

• chenile-config
• cconfig-db