Facilities and platforms

Facilities package reusable modeling definitions and generation behavior. A platform selects a concrete combination of that behavior for a CMN model.

A facility Maven artifact can contain:

• profiles (.profile) with platforms, cartridges, outlets and configuration properties;
• shared CMN models (.cmn) such as base types or method types;
• cartridge and generator implementations; and
• optional strategies, helpers and runtime integration.

The JoinedWorkz Maven plugin discovers these resources and implementations on the model module's compile classpath.

Lifecycle status and release compatibility are defined separately below.

For the surrounding concepts, see:

• Core concepts
• Modeling overview
• DSL overview
• Generated output, ownership and regeneration

1. Public support matrix

The regular public documentation covers exactly these facilities:

Facility	Status	Primary purpose
Base	Stable	Base types, REST method types, OpenAPI and diagrams
Java	Stable	Java DTO and enum generation on top of Base
SpringBoot	Stable	Spring Boot APIs, persistence, services and Flyway migrations
Quasar	Experimental	Vue/Quasar frontend fragments for modeled UX components

Stable facilities are intended for regular application development. Experimental means that the facility is available for evaluation, but its model contract, generated structure and integration requirements may still change between releases.

The lifecycle and coordinated toolchain baseline are defined in Releases, compatibility and support.

This matrix lists the built-in facilities covered by the public documentation; it is not a closed registry of every facility that can exist. Custom facilities can add platforms, cartridges, properties and outlets.

2. Maven artifacts and platform layering

The public platform relationships are:

Base
├── Java
│   └── SpringBoot
└── Quasar (experimental)

• Base — artifact org.joinedworkz.facilities:common-base; root of the public platform hierarchy.
• Java — artifact org.joinedworkz.facilities:common-java; specializes Base.
• SpringBoot — artifact org.joinedworkz.facilities:spring-boot; specializes Java and therefore also inherits Base.
• Quasar — artifact org.joinedworkz.facilities:ux-quasar; specializes Base.

Platform specialization inherits the parent platform's active behavior. Selecting SpringBoot, for example, also applies the Java and Base cartridges. Selecting Quasar also applies Base behavior to relevant model content.

Declare the highest-level facility that the model uses directly. For a SpringBoot model module:

<properties>
    <joinedworkz.version>1.3.81</joinedworkz.version>
</properties>

<dependencies>
    <dependency>
        <groupId>org.joinedworkz.facilities</groupId>
        <artifactId>spring-boot</artifactId>
        <version>${joinedworkz.version}</version>
        <scope>provided</scope>
    </dependency>
</dependencies>

spring-boot brings common-java, and common-java brings common-base. An independent target such as Quasar requires its own dependency.

The facility belongs in the model project's dependencies, not only in the Maven plugin's dependencies. See the Maven plugin reference for the exact compile-classpath contract.

3. Selecting a platform in CMN

Facility presence and platform selection are separate:

1. the Maven dependency makes profiles and models discoverable;
2. imports make referenced CMN definitions or profile namespaces available;
3. the platform declaration selects generation behavior for that model; and
4. joinedworkz.properties configures the selected cartridges and outlets.

For Base:

package com.example.api

import org.joinedworkz.facilities.common.base
import org.joinedworkz.facilities.common.base.api

platform Base

For SpringBoot:

package com.example.service

import org.joinedworkz.facilities.profiles.springboot
import org.joinedworkz.facilities.springboot.api

platform SpringBoot

A facility on the classpath does not make its platform active for every model. Conversely, selecting a platform without its facility dependency leaves the profile, models or implementation classes unresolved.

4. Package overrides for helper libraries

Generated Java can depend on small helper or glue libraries supplied by the selected facility. If you maintain a compatible implementation under your own packages, JoinedWorkz can rewrite the generated imports.

Configure mappings in the model module's joinedworkz.properties:

override-package.<original-package-prefix>=<target-package-prefix>

For example:

override-package.org.iworkz.core=com.example.glue.core
override-package.org.iworkz.spring.persistence=com.example.glue.persistence

Generated imports such as:

import org.iworkz.core.enumeration.MappedEnum;
import org.iworkz.core.query.QueryService;
import org.iworkz.spring.persistence.converter.AbstractMappedEnumAttributeConverter;
import org.iworkz.spring.persistence.service.AbstractDataAccessService;

then become:

import com.example.glue.core.enumeration.MappedEnum;
import com.example.glue.core.query.QueryService;
import com.example.glue.persistence.converter.AbstractMappedEnumAttributeConverter;
import com.example.glue.persistence.service.AbstractDataAccessService;

These two prefixes cover the default integer-enumeration glue contracts and the SpringBoot AbstractDataAccessService used by generated persistence services. A replacement data-access base owns its resulting create lifecycle, including when the generated CUSTOM ID hook runs and whether an explicit ID wins. Verify those cases separately; package rewriting proves only which implementation the generated source references. See SpringBoot ID generation strategies for that lifecycle boundary.

A production project can provide compatible implementations in its own packages and apply both overrides. After a clean regeneration and a successful build without any remaining org.iworkz reference, the application does not need a Genesis runtime dependency. JoinedWorkz Facilities remain generation dependencies and do not have to be packaged with the application.

Use this workflow:

1. copy or implement the required compatible helper API in a module you own;
2. change its package declarations to the target package;
3. configure the override-package.* mappings;
4. clean and regenerate every replaceable Java output tree;
5. compile and test the complete project against the replacement;
6. remove the original runtime dependency only after confirming that no generated or manual reference remains; and
7. repeat the clean build without the original dependency.

Current matching rules:

• matching is case-sensitive;
• the original and target prefixes must both be non-empty;
• the most specific matching package prefix wins;
• only the leading package prefix is replaced;
• the mechanism applies to imports emitted through the common Java class generator, not to arbitrary text output from every custom generator;
• it does not copy classes, change their package declarations or add Maven dependencies; and
• a clean regeneration is required after every mapping change.

See the joinedworkz.properties reference for validation and precedence details.

5. Outputs and configuration

Each facility detail page documents its public and advanced configuration, supported generation path and output ownership. These descriptions cover the four supported facilities, not a JoinedWorkz-wide closed registry:

• Base facility
• Java facility
• SpringBoot facility
• Quasar facility (experimental)

Custom facilities must document their own properties, outlet defaults, ownership and compatibility contract.

6. Next steps

• Start with the Base Quickstart.
• Learn the Consumer workflow in Profiles and platforms.
• To build and package an additional Facility, follow the separate advanced authoring guide.
• Configure generation with the joinedworkz.properties reference.
• Classify generated and manual files with the ownership reference.