Textus Samples 01:Component Script

Created: 2026-06-22 Updated: 2026-07-06

Textus Samples is a collection of small samples for learning Textus component development step by step.

This article focuses on 01.d-component-script from that collection.

01.d-component-script is not the normal Component / CML (Cozy Modeling Language) authoring path; it is a special form that uses a one-file script as a thin operational entry point.

The sample shows how a script is executed within the Component / Operation model.

The primary goal is not the implementation itself, but understanding the integration with the Textus runtime and its execution model.

Prerequisite

This article uses the environment prepared in 📄 Textus Samples: Launchers and Installation.

textus-tutorial-0.1.3 has been extracted
The cozy , cncf , and textus launchers have been installed
The runtime version for each launcher has been checked

The download steps are covered in the prerequisite article, so they are not repeated here.

What You Learn

How a scala-cli script connects to the CNCF engine runtime
That a script is still treated as a Component / Operation
A shape for small management commands

Purpose / Why This Sample Matters

This sample explains the development step for treating a Textus component operation as a small management command. Instead of first creating a large server or formal component project, the script acts as a thin entry point to the operation contract.

The focus is not the script itself, but how it creates a thin operational entry point without hiding the selector and input too much.

Concept Focus

A script is not a separate CNCF engine model; it is a thin entry point to an operation contract.
When parameters grow, the default is to model them as operation input rather than shell-specific logic.

Sample Directory

samples/01.d-component-script

Run

First, move to the sample directory.

$ cd samples/01.d-component-script

For development-time confirmation, run the script through run.sh .

$ ./run.sh

You can also run the script file directly to confirm the one-file script entry point.

$ ./script/main.scala

Command Walkthrough

run.sh internally runs scala-cli ./script/main.scala — "$@" . Therefore, the learning target is script/main.scala , not the shell wrapper itself.

script/main.scala uses a scala-cli shebang, imports the CNCF script DSL, and defines execution with run(args) { … } .

#!/usr/bin/env -S scala-cli shebang
//> using repository "https://www.simplemodeling.org/repository/maven"
//> using dep "org.goldenport:goldenport-cncf_3:0.3.14-SNAPSHOT"
import org.goldenport.cncf.dsl.script.*
@main def main(args: String*): Unit =
  run(args) { call =>
    "Hello CNCF"
  }

With this shape, even a one-file script can connect to CNCF engine runtime behavior. When the behavior grows, move toward formal Component / CML authoring instead of adding business logic to the script.

Expected Result

Hello CNCF

Reading the Output

The successful output confirms that the underlying Textus component operation ran, not merely that the shell script executed.

If the output contains a selector or result, read it by separating script responsibility from operation responsibility.

Common Pitfalls

Putting too much business logic in the shell script makes the behavior drift away from the Textus component operation contract and harder to reuse.
To avoid path-dependent scripts, the article shows only relative execution inside the downloaded package.

CNCF Engine Meaning

The script syntax is lightweight, but from the CNCF engine’s perspective it is a proper executable unit.

This means you can start small with the same runtime model before growing into a full Component project.

In the next article 📄 Textus Samples 02:Component Packaging, we examine formal packaged components and the CAR loading path.

References

In Site

Glossary

CML (Cozy Modeling Language): CML is a literate modeling language for describing Cozy models. It is designed as a domain-specific language (DSL) that forms the core of analysis modeling in SimpleModeling. CML allows model elements and their relationships to be described in a narrative style close to natural language, ensuring strong compatibility with AI support and automated generation. Literate models written in CML function as intermediate representations that can be transformed into design models, program code, or technical documentation.
Component: A software construct that encapsulates well-defined responsibilities, contracts, and dependencies as a reusable and replaceable unit. In the logical model, it serves as an abstract structural unit; in the physical model, it corresponds to an implementation or deployment unit.
Cloud Native Component Framework (CNCF): Cloud Native Component Framework (CNCF) is a framework for executing cloud application components using a single, consistent execution model. Centered on the structure of Component, Service, and Operation, it enables the same Operation to be reused across different execution forms such as command, server (REST / OpenAPI), client, and script. By centralizing quality attributes required for cloud applications—such as logging, error handling, configuration, and deployment—within the framework, components can focus on implementing domain logic. CNCF is designed as an execution foundation for literate model-driven development and AI-assisted development, separating what is executed from how it is invoked.
DSL (Domain Specific Language): A DSL (Domain-Specific Language) is a language designed for a particular domain, enabling direct and concise expression of the domain’s concepts and structures. Compared to general-purpose programming languages (GPLs), DSLs offer a higher level of abstraction tailored for domain-specific problem solving and automation.