ContentLIBRE — home

CUSTOMIZATION

Start with the foundation.
Add your difference.

Make the runtime inventory a decision. Keep project code and deployment configuration explicit, then verify the assembly you actually intend to ship.

A feature names what it brings.

ContentLIBRE’s starter assembly is additive: a bundle is present because a feature file names its coordinate. Features group capabilities such as HTTP, rendering, storage and the API. A project extension should be equally explicit about code, configuration and any repository bootstrap it contributes.

Where the documented extension model lives. text 
starter/
  platform/server/src/main/features/   Runtime capabilities
  bom/                                Consumer dependency management
customization/                        Downstream customization example

Simplified module map from ARCHITECTURE.md. Confirm exact artifact names and versions in the selected release.

FROM REQUIREMENT TO ASSEMBLY

A deliberate extension workflow.

  1. Define the capability

    Decide whether you need project code, configuration, content or a new dependency. Do not add an entire stack for a capability the platform already exposes.

  2. Declare it in the assembly

    Name the relevant bundles and feature files. Keep dependency versions and start-order requirements explicit. The upstream starter’s additive approach and a downstream prototype are different assembly patterns.

  3. Analyze, then boot

    Run the feature analyzer and the selected assembly’s integration tests. Imported packages resolving is not the same as all runtime services activating.

  4. Document the operational boundary

    Record new identities, public routes, writable paths and installation channels. Treat installed code as trusted code with the responsibilities that entails.

Project content and domain configuration are different concerns.

The site-framework model puts components, templates and frontend files in a project, while bindings belong to the deployment. This is a useful separation when the same project serves more than one environment. The site-framework document still has an unimplemented-status header while later API documentation describes site-backed modules as built; confirm exact site and authoring availability before using this model as an implementation promise.

Extend the right seam.

HTTP integrations

Use the documented Jakarta REST module conventions when your project publishes typed operations.

Read the API guide

Authoring experiences

The site document describes a versioned server seam with a demonstration shell. A complete business editor is not established by the published evidence.

Check authoring status

Page lifecycle rules

Reactors, validators and subscribers belong to the proposed lifecycle layer. Explore the design without compiling against an assumed released API.

Read the design preview

Keep every addition understandable.

A small, well-described extension is easier to evaluate than a feature list with hidden dependencies.

Read the architecture Security and operations