JoinedWorkz
Docs1.3.81

Appearance

Examples ​

This section collects example projects and records their purpose and release compatibility alongside the documentation.

The focus is on small, focused examples that demonstrate specific JoinedWorkz concepts:

  • how to structure CMN and profile models
  • how to wire the Maven plugin and facilities
  • how generation and outlet overrides work in real projects

For each example, distinguish authoritative inputs, manual sources and generated outputs. The common rules and commit-policy alternatives are in Generated output, ownership and regeneration.

The examples require Java 21 and Maven 3.9+. Quasar remains experimental; the other examples state their support status on their respective pages.

1. JoinedWorkz quickstart ​

The standalone joinedworkz-quickstart repository on release/1.3.81 is the canonical source project for the Base Quickstart. The release branch and the documentation Quickstart use Java 21 and Maven 3.9 or newer. The documentation POM and model match that source project.

2. Java facility examples ​

The stable Java facility has two deliberately separate public examples:

Each module is independently buildable and has one primary learning purpose. Neither module creates a runnable server: the Java facility generates data types and inherits specification output from Base, but it does not supply an application framework.

The Java facility examples page shows how to build both modules, which output to inspect and which files remain replaceable.

3. Spring Boot reference demo ​

The public joinedworkz-demo repository is the runnable multi-module Spring Boot reference project for JoinedWorkz 1.3.81. Its main structure is:

text
joinedworkz-demo/
├── ai/
│   ├── joinedworkz-context-core/
│   └── project-context/
├── model/
├── backend-spring-core/
└── backend-spring-app/

The model module owns the CMN source and generator configuration. backend-spring-core deliberately combines replaceable generated Java and OpenAPI output, an application-owned first-cut handler and value converter, and persistent Flyway history. backend-spring-app contains the runnable manual application shell, configuration and focused tests.

The demo models Request, User and a RequestView with an optional assignee reference. Its HTTP list operation uses a genuinely paginated native SQL projection, while the detail operation demonstrates JPQL as the default query language. RequestHandlerImpl, CommonValueConverter and the manual HTTP integration test show the application-owned integration boundary around the generated Spring code.

4. Spring Boot CRUD example ​

In addition to the Base-only quickstart there is a Spring Boot example that demonstrates how the SpringBoot facility and its entity CRUD generators work together:

The example contains:

  • a customer entity model,
  • an API model that uses the createEntity, readEntity, updateEntity, queryEntities and deleteEntity method types,
  • a component model that provides the customer resource and names its controller,
  • generated Spring Boot controllers,
  • generated DataAccessService classes for persistence,
  • generated mapper interfaces between DTOs and entities,
  • a manually maintained Spring Boot application shell, and
  • a manual HTTP runtime test covering create, read, query, update and delete;
  • a separate synthetic id-generation.cmn model for CUSTOM and JPA UUID; and
  • three H2-backed ID-generation runtime cases in addition to the Customer and repository-statement tests.

The API model for the customer CRUD endpoints looks roughly like this:

cmn
api package org.joinedworkz.examples.customer.api

import org.joinedworkz.examples.customer

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

platform SpringBoot

resource /customers as Customer[] by id {

    queryEntities()
    createEntity()
    readEntity()
    updateEntity()
    deleteEntity()  
}

abstract resource /address as Address { }

The component model binds that resource to the generated HTTP boundary:

cmn
package org.joinedworkz.examples.backend

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

platform SpringBoot

component CustomerBackend
    componentNamespace='org.joinedworkz.examples.customer.webapp' {

    provide /customers
        namespaceSuffix='customers.v1'
        controller="CustomerV1Controller" {
    }
}

Together, the domain, API and component models generate under src/generated/**:

  • CustomerV1Controller and its API interface from the component's provide /customers boundary,
  • CustomerDataAccessService with CRUD operations,
  • a mapper interface between the generated DTO and the entity type,
  • wiring between controller and data access service, including mapping.

The Base cartridge also writes the model-scoped customer API document and an additional CustomerBackend OpenAPI document aggregating all endpoints provided by that component.

The example keeps the opt-in generated integration-test cartridge disabled. Its manual CustomerCrudRuntimeTest starts the application on a random port and verifies the complete generated CRUD boundary through HTTP, JSON, MapStruct, JPA and H2. The separate IdGenerationRuntimeTest exercises missing and explicit IDs through generated data-access services without changing the Customer model's assigned-ID contract. Read the ID generation strategy reference for the supported lifecycle and provider boundary. The Spring Boot CRUD guide contains the build, start and request walkthrough.

5. Experimental Quasar example ​

The public example-ux-quasar module combines a small generated Spring Boot and H2 backend with an executable manual Quasar application shell. It shows the ownership boundary around generated pages, routes and the application store, integrates those fragments into the manual router and layout, and connects a modeled componentRef to a manual Vue component.

The widget is declared in a separate imported model without its own platform. The complete example therefore also demonstrates that the platform belongs to the consuming UX model rather than to a reusable widget definition.

Use Quasar example: executable experimental frontend for the build, development proxy, H2 flow, regeneration checks and explicit experimental boundaries.

6. Custom Facility and additional Platform example ​

The example-custom-facility module packages a small TextReport Facility and consumes it from an independent Maven project. It also verifies a Profile-declared Strategy that calculates a Core Model property, an explicit CMN override of that value and a generator that consumes the resulting property without rerunning the Strategy. Alongside the direct consumer, it contains a Base model and a TextReport wrapper that prove how an importer can contribute one missing Cartridge without replacing the imported model's Platform or namespace.

Start with Build a custom Facility for the complete packaging and consumption path. The focused composition contract is explained in Imported model processing and diagnostics. The Strategy lifecycle is documented in Profile Strategies and calculated properties.