File header & packages
The CMN file header defines how a model file is structured and interpreted. It declares the package and optional layer, followed by imports and the selected platform.
Complete example
core package com.example.customer
import org.joinedworkz.facilities.common.base
import org.joinedworkz.facilities.common.base.api
platform Base
subpackage api {
type CustomerView {
id*: Id
name*: Name
}
}
type Customer {
id**: Id
name*: Name
}The declarations must appear in this order: root package, imports, platform, then subpackages and model elements.
1. Package and layer
package com.example.customerThe package is the logical namespace for the model elements in the file. An optional layer is a free identifier immediately before package:
core package com.example.customerThere is no layer keyword. The meaning of a layer is facility- and generator-specific; for example, a facility can use it for tagged outlet routing.
2. Subpackages
Subpackages require a block and occur after the root header:
package com.example.customer
subpackage api {
type CustomerView {
id*: Id
}
}The elements in this block belong to com.example.customer.api. Imports and the platform are declared on the root model, not inside the subpackage.
3. Platform selection
platform BaseThe platform determines which profile, cartridges, and properties are applied. Base, Java, and SpringBoot are stable public platforms in JoinedWorkz 1.3.80.
4. Imports
import org.joinedworkz.facilities.common.base
import org.joinedworkz.facilities.common.base.apiThe first package contains the Base types. The second contains Base resource method types and API helper types. Imports can also make resources, services, components, and other model elements visible.
5. Aliases
import com.example.shared as sharedAn alias is a single identifier used before :::
type AuditInfo {
createdAt: shared::Timestamp
}The imported package must define the referenced type. A dotted package name cannot be placed before ::; use an alias or an imported simple name.
