Harmonize naming of Open Pioneer Trails

CHANGELOG.md

@@ -14,5 +14,5 @@
 
 ## 2024-03-14
 
--   Update to latest open pioneer trails packages
+-   Update to latest Open Pioneer Trails packages
 -   Update to OpenLayers 9

README.md

@@ -1,4 +1,4 @@
-# Open Pioneer Starter
+# Open Pioneer Trails Starter
 
 ![Build status](https://github.com/open-pioneer/trails-starter/actions/workflows/test-and-build.yml/badge.svg) ![Dependency audit](https://github.com/open-pioneer/trails-starter/actions/workflows/audit-dependencies.yml/badge.svg)
 

docs/BestPractices.md

@@ -89,7 +89,7 @@ Both `dependencies` and `peerDependencies` refer to packages required at runtime
 We'll reuse the rules defined in that post. Use `peerDependencies` if at least _one_ of these conditions apply:
 
 -   Having multiple copies of a package would cause conflicts.
-    > This is especially the case for open pioneer packages as we do not support open pioneer packages in multiple versions.
+    > This is especially the case for Trails packages as we do not support Trails packages in multiple versions.
     > "plain" npm packages can often be duplicated though, if absolutely necessary.
 -   The dependency is visible in your interface
 -   You want the developer to decide which version to install
@@ -104,7 +104,7 @@ You can use `devDependencies` to force a specific (e.g. very new) version to pro
 The guidelines above only leave very few occasions where a "normal" dependency is appropriate.
 Use `dependencies` if _all_ of the following is true:
 
--   The dependency in question is not an open pioneer package
+-   The dependency in question is not a Trails package
 -   Having multiple versions will not introduce conflicts (e.g. React should never be present more than once)
 -   The usage of that package is entirely internal, i.e. not part of your package's interface.
     This could be the case for internal helpers, parsers, etc.

docs/Glossary.md

@@ -15,14 +15,7 @@ Apps are developed in application packages.
 ## Application package
 
 A package that provides an app (typically in `app.js` or `app.ts`).
-Application packages are also pioneer packages.
-
-## Pioneer package
-
-A special package type that serve as the building blocks of an app.
-Pioneer packages may define and use services and UI components.
-The packages used by an app are automatically linked into the application.
-The build system ensures that the code (and assets) required are automatically loaded.
+Application packages are also Trails packages.
 
 ## Package
 
@@ -44,3 +37,10 @@ References to services are handled by the system, which will inject appropriate
 
 Pioneer packages may be compiled (and distributed) independently from other packages or the context of a specific application.
 These packages can be linked together into an application using our build tooling.
+
+## Trails package
+
+A special package type for the Open Pioneer Trails framework that serve as the building blocks of an app.
+Trails packages may define and use services and UI components.
+The packages used by an app are automatically linked into the application.
+The build system ensures that the code (and assets) required are automatically loaded.

docs/Introduction.md

@@ -1,6 +1,6 @@
 # Introduction
 
-The open pioneer client framework supports the creation of client side web applications.
+The Open Pioneer Trails framework supports the creation of client side web applications.
 It offers a simple architecture where an application can be assembled from a set of packages.
 Packages are reusable components that can be used in multiple applications and with different configuration.
 When an application is built, it can be deployed either as a single (or multi-) page application or as an easily embeddable Web Component.

docs/README.md

@@ -1,4 +1,4 @@
-# Open Pioneer Documentation
+# Open Pioneer Trails documentation
 
 ## Table of contents
 

docs/RepositoryGuide.md

@@ -262,7 +262,7 @@ function MyComponent() {
 ### Vite
 
 [Vite](https://vitejs.dev/) is our main build tool and development server.
-Custom functionalities (such as our specific pioneer-framework package support) are developed on top of Vite via plugins.
+Custom functionalities (such as our specific Open Pioneer Trails framework package support) are developed on top of Vite via plugins.
 
 Vite reads the configuration file `vite.config.ts` on start, which can be customized to your liking
 (see [docs](https://vitejs.dev/config/)).

docs/internals/BuildTools.md

@@ -39,7 +39,7 @@ Reading and validation of the `build.config.mjs` are implemented here, as well a
 
 ### Overview
 
-Every local package in a pioneer application contains a `build.config.mjs` and a `package.json` file, together defining the package's metadata.
+Every local package in an Open Pioneer Trails application contains a `build.config.mjs` and a `package.json` file, together defining the package's metadata.
 Package metadata includes:
 
 -   The packages name, version, etc.

docs/internals/Design_Phase2.md

@@ -2,9 +2,9 @@
 
 ## Introduction
 
-This document contains the design for the second implementation phase of the pioneer framework.
+This document contains the design for the second implementation phase of the Open Pioneer Trails framework.
 The goal of this phase is to enable development across multiple repositories, i.e. using non-local packages
-in an open pioneer app and sharing such packages with other developers.
+in an Open Pioneer Trails app and sharing such packages with other developers.
 
 Note that most aspects in this document are concerned with _packages_, not with _apps_.
 Building and distributing an application is a problem solved with phase 1, and only a few modifications
@@ -32,13 +32,13 @@ It may in fact be a disadvantage because it makes generated code harder to read
 
 -   A build tool that compiles a single package, handling TypeScript/JavaScript/JSX, CSS and assets such as README or LICENSE files.
 -   A tool to publish such a compiled package to a registry
--   Existing build tools must be able to handle external packages with pioneer extensions
+-   Existing build tools must be able to handle external packages with Open Pioneer Trails extensions
 -   Configuration / Documentation: How to build and host api docs
 -   Documentation: How to use an external package
 
 ## Assumptions
 
--   All packages will ultimately be built using vite, with our pioneer vite plugin enabled.
+-   All packages will ultimately be built using vite, with our Open Pioneer Trails vite plugin enabled.
     Applications will always contain our matching runtime package.
     This gives us some leeway w.r.t. special vite imports (e.g. `?inline`) - we can just pass them through and not replace them at all.
 
@@ -112,22 +112,22 @@ It may in fact be a disadvantage because it makes generated code harder to read
 
     It is easier and more performant to put metadata in the `package.json`.
     It does not have to be edited by hand and we have to open the `package.json` anyway during package discovery.
-    This makes the answer to the question "does this package use open pioneer features" very quick to answer.
+    This makes the answer to the question "does this package use Open Pioneer Trails features" very quick to answer.
 
 ## Build plugin
 
-The existing vite plugin must be extended to handle pioneer packages from `node_modules`.
+The existing vite plugin must be extended to handle Open Pioneer Trails packages from `node_modules`.
 Vite handles node packages from `node_modules` just fine on its own, but our own build plugin ignores them currently.
 
 They must not be be ignored in the future because the services, properties and styles from such a package must be linked into the application,
 which is the responsibility of our plugin.
 
-Vite build plugin will scan all dependencies (local and non-local) of an app to check whether they are either local or use pioneer extensions (check for presence of `openPioneer` in `package.json`).
+Vite build plugin will scan all dependencies (local and non-local) of an app to check whether they are either local or use Open Pioneer Trails extensions (check for presence of `openPioneer` in `package.json`).
 For local packages, the process stays as it is.
 For non-local packages (in `node_modules`) the recursive search continues until a "non-pioneer" package is found, which will then be ignored just as before.
 All services, properties etc. of discovered packages will then be linked into the application.
 
-Note that this search will not discover pioneer packages that are dependencies of "plain" packages, i.e.
+Note that this search will not discover Trails packages that are dependencies of "plain" packages, which means
 
     "app" -> "package without openPioneer" -> "package with openPioneer"
 

docs/internals/ServiceLayer.md

@@ -1,6 +1,6 @@
 # Service Layer
 
-This document contains details about the implementation of the pioneer runtime's service layer.
+This document contains details about the implementation of the Open Pioneer Trails runtime's service layer.
 It should aid developers to gain an understanding of the implementation in order to maintain or extend it.
 
 The service layer provides a generic dependency injection mechanism in which services can be defined.

docs/reference/Package.md

@@ -2,7 +2,7 @@
 
 ## Introduction
 
-This document specifies the structural requirements for an open pioneer package in the source directory.
+This document specifies the structural requirements for a Trails package in the source directory.
 
 > This specification applies to both apps and "normal" packages.
 > Apps are simply packages that expose a web component: they may use all package features such as services etc.

docs/reference/Theming.md

@@ -2,7 +2,7 @@
 
 When developing Open Pioneer Trails applications, arbitrary [React](https://reactjs.org/) components can be used to create the user interface.
 However, we mostly use pre-defined components from the Chakra UI framework.
-Chakra UI comes with a theming mechanism that is re-used in trails and briefly explained here.
+Chakra UI comes with a theming mechanism that is re-used in Open Pioneer Trails and briefly explained here.
 
 To get an example of how to create a theme for your app, refer to [How To Theme An App](../tutorials/HowToThemeAnApp.md).
 
@@ -19,12 +19,12 @@ There are two internal levels of theming and a third level for an app-specific c
 The first level is Chakra UI's default theme which defines the _default look_ of Chakra UI
 components and is part of Chakra UI.
 
-The second internal level is the Trails base theme which is part of the Trails Core Packages.
+The second internal level is the Trails base theme which is part of the Trails core packages.
 It defines common variables ([semantic tokens](https://chakra-ui.com/docs/styled-system/component-style))
 and a default color scheme that is used as a default color scheme for all Chakra UI components.
 This theme is active by default in Trails applications, but it is also designed to be extended.
 Most custom themes are expected to extend this theme (via Chakra's `extendTheme()` function) while making only minor adjustments.
-The Trails base theme will be extended in future releases of the Trails Core Packages.
+The Trails base theme will be extended in future releases of the Trails core packages.
 
 The third level of theming is a custom theme that can be passed to a Trails app via the optional `theme` option in `createCustomElement`.
 When specified, the custom theme replaces the Trails base theme as the application's active theme.
@@ -37,4 +37,4 @@ Changes to the theme will therefore always affect multiple component instances.
 To style _specific_ elements in a different way, the developer has to use CSS rules or inline styles.
 
 The [`Sample UI`](https://github.com/open-pioneer/trails-core-packages/tree/main/src/samples/chakra-sample/chakra-app)
-app in the Trails Core packages provides an example for a custom theme.
+app in the Trails core packages provides an example for a custom theme.

docs/tutorials/HowToCreateAPackage.md

@@ -34,7 +34,7 @@ We will create a package called `hello-world` that exports a simple function:
 import { defineBuildConfig } from "@open-pioneer/build-support";
 
 // The empty object is the minimal configuration.
-// We're not going to use any custom features from the pioneer framework for now.
+// We're not going to use any custom features from the Open Pioneer Trails framework for now.
 export default defineBuildConfig({});
 ```
 

docs/tutorials/HowToCreateAnApp.md

@@ -11,7 +11,7 @@ This repository comes prepared with an empty app in `src/apps/empty`, which is e
 To create the application package for an app, first initialize a `package.json` file in a new directory.
 Application packages should by convention be placed in `src/apps/<APP_NAME>`, but technically they may be placed anywhere in the `src` directory.
 
-All pioneer packages are node packages to benefit from (p-)npm's dependency management.
+All Trails packages are node packages to benefit from (p-)npm's dependency management.
 Create a very simple [`package.json`](https://docs.npmjs.com/cli/v9/configuring-npm/package-json) such as this:
 
 ```jsonc
@@ -66,11 +66,11 @@ const Element = createCustomElement({
 customElements.define("my-app-element", Element);
 ```
 
-This is the setup required for a minimal pioneer application:
+This is the setup required for a minimal Open Pioneer Trails application:
 
 -   **(1)**
     `createCustomElement` is the central framework function responsible for defining the actual web component.
-    It is exported by `@open-pioneer/runtime`, a package all pioneer applications must depend on.
+    It is exported by `@open-pioneer/runtime`, a package all Open Pioneer Trails applications must depend on.
 
 -   **(2)**
     The special `open-pioneer:app` module provides automatically gathered metadata about your application.

docs/tutorials/HowToCreateUiComponents.md

@@ -1,6 +1,6 @@
 # How to create UI components
 
-When developing applications with the open pioneer client framework, [React](https://reactjs.org/) can be used to create UI components.
+When developing applications with the Open Pioneer Trails client framework, [React](https://reactjs.org/) can be used to create UI components.
 We can also use pre-defined components from the [Chakra UI](https://chakra-ui.com/) framework.
 
 ## Documentation

docs/tutorials/HowToPublishAPackage.md

@@ -1,14 +1,14 @@
 # How to publish a package
 
-This tutorial describes how to share a pioneer package with other developers.
+This tutorial describes how to share a Open Pioneer Trails package with other developers.
 You can skip this document if you're just working in the context of a single application.
 
 Until now, this manual has only been concerned with building an _application_, possibly including a set of _local_ packages.
 The result of building an application is always a set of static files (.i.e. `.html`, `.js`, etc.) that can be interpreted by a browser.
 This output is ideal for distributing a final application, but it is not suitable for sharing reusable parts of your application.
 
-One of the key advantages of the open pioneer client framework is the ability to scale up application development by sharing reusable application components as packages.
-Shared open pioneer packages are similar to "plain" node packages (in fact, they _are_ node packages), but they come with the additional feature set you have learned already:
+One of the key advantages of the Open Pioneer Trails client framework is the ability to scale up application development by sharing reusable application components as packages.
+Shared Trails packages are similar to "plain" node packages (in fact, they _are_ node packages), but they come with the additional feature set you have learned already:
 services of a package are automatically started when needed, styles are automatically applied, etc.
 
 There are some things to consider and a few steps to follow when indenting to share a package with other developers.
@@ -34,7 +34,7 @@ We will first discuss the underlying concepts and then work through a specific e
 -   **Package installation**
 
     After a package has been published, it can simply be installed in any project, e.g. by executing `pnpm add`.
-    Our build tools automatically detect pioneer packages in an app's dependency graph.
+    Our build tools automatically detect Trails packages in an app's dependency graph.
     A package installed this way should work the same way _as if_ it were developed locally.
 
 ### Package compilation
@@ -46,7 +46,7 @@ It can be installed by adding [`@open-pioneer/build-package-cli`](https://www.np
 $ pnpm add -w -D @open-pioneer/build-package-cli
 ```
 
-It is designed to be invoked from the source directory of a pioneer package and reads its configuration from that package's `package.json` and `build.config.mjs` (see [Reference](../reference/Package.md#publishconfig)).
+It is designed to be invoked from the source directory of a Trails package and reads its configuration from that package's `package.json` and `build.config.mjs` (see [Reference](../reference/Package.md#publishconfig)).
 After successful execution, it will have assembled a compiled version of that package in the `dist` directory (in that package's source directory).
 
 `build-pioneer-package` also performs some validation to enforce best practices and to catch common errors.
@@ -141,7 +141,7 @@ Package compilation involves the following steps:
     Most properties from your package's source `package.json` will simply be copied into the generated `package.json` (such as `name`, `version` and many more).
 
     When generating the `package.json`, `build-pioneer-package` also takes into account your package's metadata from the `build.config.mjs`: it will make entry points public (via `exports`) and include
-    information about services and other open pioneer features using the `openPioneerFramework` property.
+    information about services and other Open Pioneer Trails features using the `openPioneerFramework` property.
 
 -   **Copy auxiliary files.**
 
@@ -395,7 +395,7 @@ We have also been told to configure `publishConfig.directory`:
 }
 ```
 
-Because the core package is a pioneer package, we have added it as a `peerDependency` (see [Best Practices](../BestPractices.md#dependency-management)).
+Because the core package is a Trails package, we have added it as a `peerDependency` (see [Best Practices](../BestPractices.md#dependency-management)).
 We also added `linkDirectory: false`, see [Publishing](#publishing).
 
 #### Adding required files

docs/tutorials/HowToThemeAnApp.md

@@ -8,7 +8,7 @@ mechanism in Open Pioneer Trails apps, refer to [Theming](../reference/Theming.m
 To show how a custom theme for an app can be created, we will extend the empty app
 (at `src/apps/empty`).
 
-By default, the app is shown in a theme specified in the Trails Core packages.
+By default, the app is shown in a theme specified in the Trails core packages.
 To overwrite some or all styles (e.g. the "trails" color scheme), a custom app-theme can be created.
 
 ## Create custom theme
@@ -102,13 +102,13 @@ export const theme = extendTheme(
 ```
 
 -   **(1)** Import the `extendTheme` helper function.
--   **(2)** Import the trails base theme from the "@open-pioneer/base-theme" package.
--   **(3)** Use `extendTheme` to create an own theme based on the trails base theme.
+-   **(2)** Import the Trails base theme from the "@open-pioneer/base-theme" package.
+-   **(3)** Use `extendTheme` to create an own theme based on the Trails base theme.
 -   **(3.1)** Chakra UI theming object that defines the custom theme.
     (The object specified here is only used as an example.)
--   **(3.2)** Specify the theme to extend (here: the trails base theme).
+-   **(3.2)** Specify the theme to extend (here: the Trails base theme).
 
-Hint: The trails base-theme introduces some special semantic tokens.
+Hint: The Trails base theme introduces some special semantic tokens.
 For information about which values are available, see the base-theme core package code.
 
 ### Use a Chakra UI color scheme