This document describes the design tokens system in PatternFly Java, which bridges PatternFly's CSS design tokens (CSS custom properties) to type-safe Java enums. Design tokens provide a consistent set of design values (colors, spacing, typography, etc.) that ensure visual consistency across components.
The tokens module generates Java code from PatternFly CSS variables during the build process, making design system values accessible to Java developers. For information about icon generation, see Icon System. For general core architecture patterns, see Core Architecture.
Sources: High-level architecture overview, tokens/pom.xml
Design tokens are named design decisions (colors, spacing units, font sizes, etc.) that form the foundation of the PatternFly design system. In PatternFly's CSS implementation, these are defined as CSS custom properties like --pf-v5-global-Color--100 or --pf-v5-global-spacer--md.
The tokens module transforms these CSS variables into Java enums, providing:
| Benefit | Description |
|---|---|
| Type Safety | Compile-time checking prevents typos in CSS variable names |
| IDE Support | Autocomplete and refactoring tools work with enum constants |
| Consistency | Centralized source of truth from PatternFly CSS |
| Discoverability | Developers can browse available tokens via enum values |
The generated Java code depends only on patternfly-java-core, making tokens available to all component modules.
Sources: tokens/pom.xml:35-40
The following diagram illustrates how CSS custom properties are transformed into Java enum constants:
Diagram: Token Generation Pipeline from CSS to Java
The pipeline executes during Maven's generate-sources phase, ensuring tokens are available before Java compilation begins. The generated Token.java file is tracked in source control cleanup rules but regenerated on each build.
Sources: tokens/pom.xml:44-93
The tokens module uses frontend-maven-plugin to execute Node.js-based generation scripts within the Maven build lifecycle:
Diagram: Frontend Maven Plugin Execution Flow
All three executions are bound to the generate-sources phase (tokens/pom.xml64-91), ensuring they complete before Java compilation. The plugin configuration references ${version.node} from the parent POM's properties.
Sources: tokens/pom.xml:58-93
The Maven Clean plugin is configured to remove generated source files:
| Configuration Element | Value | Purpose |
|---|---|---|
| Directory | src/main/java/ | Target directory for cleanup |
| Include Pattern | org/patternfly/token/Token.java | Specific file to remove |
This configuration ensures that mvn clean removes generated tokens, forcing regeneration on the next build. The generated file is placed in the source tree rather than target/ to support IDE integration and debugging.
Sources: tokens/pom.xml:44-57
The tokens module packages as gwt-lib (tokens/pom.xml31) with the GWT module name org.patternfly.Tokens (tokens/pom.xml98). This packaging type includes both compiled .class files and .java source files in the JAR, which is required for GWT compilation.
Sources: tokens/pom.xml:31, tokens/pom.xml:94-100
While the actual generated Token.java file is not provided in the source files, based on the module configuration and design system patterns, the generated code follows this structure:
Diagram: Token.java Enum Structure
Each enum constant corresponds to a PatternFly CSS custom property. The enum provides methods to retrieve the actual CSS variable name (e.g., --pf-v5-global-Color--100) for use in style attribute values.
Sources: tokens/pom.xml:52 (file path reference)
Based on PatternFly's design token taxonomy, generated tokens likely include:
| Category | CSS Prefix | Example Tokens |
|---|---|---|
| Colors | --pf-v5-global-Color-- | Primary, secondary, danger, success colors |
| Spacing | --pf-v5-global-spacer-- | XS, SM, MD, LG, XL spacing units |
| Typography | --pf-v5-global-FontSize-- | Font sizes, weights, line heights |
| Borders | --pf-v5-global-BorderWidth-- | Border width values |
| Shadows | --pf-v5-global-BoxShadow-- | Elevation shadow values |
| Breakpoints | --pf-v5-global-breakpoint-- | Responsive breakpoint values |
Each category maps to a set of enum constants, organized logically within the single Token enum.
Sources: General PatternFly design system knowledge, tokens/pom.xml module structure
Components depend on the tokens module to access design tokens:
The BOM manages version consistency, so components typically omit the <version> element.
Sources: tokens/pom.xml:23-28 (parent structure), general Maven dependency patterns
Components use tokens when setting CSS custom properties or inline styles via Elemento's builder API. Example usage pattern:
The tokens provide a type-safe bridge between Java code and PatternFly's CSS variable system, ensuring components use approved design system values rather than hardcoded strings.
Sources: tokens/pom.xml:35-40 (core dependency for base functionality)
Diagram: Tokens Module in Dependency Graph
The tokens module sits at the foundation layer, depending only on core and providing tokens to all higher-level modules. This positioning ensures tokens are available throughout the component hierarchy without circular dependencies.
Sources: tokens/pom.xml:35-40, high-level architecture overview
The clean plugin configuration (tokens/pom.xml44-57) ensures consistent generation behavior:
mvn clean - Removes Token.java from source treemvn generate-sources - Installs Node.js, dependencies, generates new Token.javamvn compile - Compiles generated Java codemvn package - Creates gwt-lib artifact with sources and classesThis workflow guarantees that tokens always reflect the current PatternFly CSS version declared in package.json.
Sources: tokens/pom.xml:44-93
While the actual package.json is not provided, the Maven configuration reveals:
| NPM Command | Maven Phase | Purpose |
|---|---|---|
npm install | generate-sources | Install dependencies including @patternfly/patternfly |
npm run generate | generate-sources | Execute token generation script |
The generation script likely parses PatternFly's CSS files, extracts custom property declarations, and generates Java enum constants with appropriate naming conventions (converting kebab-case CSS variables to SCREAMING_SNAKE_CASE enum constants).
Sources: tokens/pom.xml:72-91
The gwt-lib packaging type (tokens/pom.xml31) produces a JAR containing:
.class files for standard Java usage.java source files for GWT/J2CL transpilationorg.patternfly.Tokens)This dual-content approach allows the same artifact to serve both GWT/J2CL projects (which need sources for transpilation) and standard Java projects (which use compiled classes).
Sources: tokens/pom.xml:31, tokens/pom.xml:94-100
The tokens module inherits its version from the parent POM:
This ensures all PatternFly Java modules maintain synchronized versions, managed centrally through the root POM and BOM module.
Sources: tokens/pom.xml:23-28
The design tokens system provides a critical bridge between PatternFly's CSS-based design system and Java component code:
| Aspect | Implementation |
|---|---|
| Input | PatternFly CSS custom properties from NPM package |
| Generation | Node.js script executed via frontend-maven-plugin |
| Output | Token.java enum with type-safe constants |
| Build Phase | generate-sources (before Java compilation) |
| Packaging | gwt-lib with sources and classes |
| Dependencies | Depends on core, used by components and layouts |
The system ensures that Java components use consistent design values without hardcoding CSS variable names, providing type safety, IDE support, and a single source of truth derived directly from the official PatternFly design system.
Sources: tokens/pom.xml (entire file), high-level architecture overview
Refresh this wiki