The Foundation has received a complete makeover. Instead of pure technical documentation listed per topic, everything is now organized around specific needs relating documentation: what is this, how do I do this, what exactly are the options. This blogpost explains how everything is restructured, where to find what you need, what is still incomplete, and how you can help.

Three sections, three needs​

The Foundation is now split into three main sections. Each one answers a different kind of question or need, and most topics appear in all three, each time from a different angle. A fourth section was created to gather NST related content.

1. Software Ecosystem: "What is this, and how does it fit together?"​

The Software Ecosystem is the place to start if you are new to a product or concept. It explains what things are and why they exist, without step-by-step instructions or long lists of attributes. It is organized into two main categories:

• Engineering Platform: Prime Radiant, Micro Radiant and the engineering utilities
• Engineering Solutions: The solutions you can build. NS Applications, expanders, metamodel, plugins

2. Developer Hub: "How do I do this?"​

The developer hub gathers guides, tutorials, technical blogs, and contains information on our development process. Developer Guides are practical step-by-step guides that range from getting started with a product, to performing complex tasks. The developer guides can be classified as "How To's". In procedure guides you will be able to scan through various scenarios, which will lead you to the correct documentation for your specific situation.

3. Reference Guides: "What exactly can I do with this product?"​

The precise technical documentation you look up while working: model elements, attributes, options, file formats and APIs. The Reference Guides are considered to be our single source of truth. This way, developer guides do not contain any new facts, these are all stored here. Most content of the old Foundation can be found here, rather unchanged. The General section collects the reference that isn't tied to a single product, such as expansionSettings.xml.

A fourth section, is "NST Knowledge". In this section, you can find everything NST - related. The theory itself, theoretic articles, white papers, youtubbe videos. An important addition to the Foundation is the glossary (located in NST knowledge). Here you can find the most important terminology, to make sure we use the same understanding of concepts.​

A Work in Progress​

We have moved the current existing documentation, extended the topics with functional sections for the ecosystem, and gathered or extracted developer guides. But, we are not yet done. Some thing you may notice that will be fully covered in the next few weeks:

• Developer Guides are incomplete. Every product currently has a list of developer guides. However, a fair amount of topics don't have the complete set of "how to's" yet that they deserve. More step-by-step guides, basics as well as advanced, will follow.

• Some content can be found twice. The split between developer guides and reference guides is a challenging one. Since step-by-step guides used to be intertwined with option definitions, attributes lists, and important facts, you may find that some content is still placed in both sections. This separation is also an ongoing effort.

• Procedure Guides is in a sample state. The procedure guides serve as a way to browse situations. However, the content is currently only sample data for a couple of scenarios. This will still need to be completed.

• Links may point to old locations. Pages have moved, and not every link has caught up yet. We have tried our very best to update every link, but a few dead ones might still be left.

Important to note, is that we have not removed anything from the old documentation yet. It is just hidden from the menu items. If something is missing, unclear or wrong, please let us know.

Foundation Contribution​

Separated according to our different needs, every piece of information will have a clear home. When adding new content, this might be a little challenging at the beginning. To know where content belongs, we have relied on asking ourselves the following questions:

• Does it explain what something is or why it exists? It goes in the Ecosystem.
• Does it describe how to do something, step by step? It goes in the Developer Hub.
• Does it list exact facts, such as attributes, options, versions or file formats? It goes in the Reference Guides.

We hope everyone will easily find their way in this newly structured Foundation, and we are happy to gather feedback!

Angular 22​

The angular-expanders have upgraded to Angular 22. It is possible to use the new features and enhancements of this update. Angular 22 also addresses various security vulnerabilities.

Base feature modules​

This is only available when using the standard-api

The base-components (account, assets, utils) could be accessed through the knockout UI, but this wasn't yet possible in the Angular UI. Now that has changed. Next to the base-components there are now base-feature-modules which allow us to include some default feature modules. With this update there are corresponding feature modules for the account, assets and utils base components. Allowing you to access and update these components and data elements just as in the knockout UI.

This includes a custom My User page accessible via the user icon in the top right. On this page users can see their own info and change their password (the password only applies for basic auth). The ability to view their info and change their password can be configured through the data access.

<angularApp
    xmlns="https://schemas.normalizedsystems.org/xsd/angularProjects/7/0/0"
    type="angularProjects::AngularApp">
    ...
  <featureModules>
    ...
    <featureModule>utils</featureModule>
    <featureModule>account</featureModule>
    <featureModule>assets</featureModule>
  </featureModules>
</angularApp>

Menu changes​

• By default, a menu is expanded to access each data view.
• More customization possibilities e.g. change the menu based on the user profile.
• A new method updateIcon was added. This method changes the icon of a MenuItem at runtime.

Application properties​

This is only available when using the standard-api

You can access the application properties through a button in the bottom left of the sidebar. This will show metadata about the application, such as the version, used expansion resources and more.

Direct imports​

The imports defined in the mapping files of Angular expanders required the use of the from keyword. However some imports don't use, and can't use the from keyword. Therefore a new direct import type has been created to allow imports without the from keyword.

<uses type="direct" eval="'prismjs'"/>  // import "prismjs";

Generate default Angular app​

The GenerateDefaultAngularApp transmuter will add an AngularApp to your project, if not already present. It will also generate FeatureModules, DataConnectors and DataViews based no the elements model. The transmuter can be performed multiple times and is a great way to keep the elements model and Angular model in sync.

Migration guide​

Versions​

The angular-beam::1.0.0 requires net.democritus:base-components::2026.6.0. The base-components are included in the minimal-jee-beam and jee-backend-beam, so updating them will satisfy this requirement.

<expansionResources>
  ...
  <expansionResource name="org.normalizedsystems.beam:minimal-jee-beam" version="2.3.0"/>
</expansionResources>

<expansionResources>
  ...
  <expansionResource name="org.normalizedsystems.beam:jee-backend-beam" version="1.1.0"/>
</expansionResources>

When using Angular in combination with the standard-api as the control layer you should use the following.

<expansionResources>
  ...
  <expansionResource name="org.normalizedsystems.beam:angular-beam" version="1.0.0"/>
  <expansionResource name="net.democritus.angular.stdapi:angular-stdapi-expanders" version="4.0.0"/>
  <expansionResource name="org.normalizedsystems.beam:standard-api-beam" version="2.0.0"/>
</expansionResources>

When using Angular in combination with the service-api as the control layer you should use the following.

<expansionResources>
  ...
  <expansionResource name="org.normalizedsystems.beam:angular-beam" version="1.0.0"/>
  <expansionResource name="net.democritus.angular.svcapi:angular-svcapi-expanders" version="3.8.0"/>
  <expansionResource name="org.normalizedsystems.beam:service-api-beam" version="1.3.0"/>
</expansionResources>

Angular 22​

Node version requirement​

The minimum required node version has changed to ^22.22.3 || ^24.15.0 || ^26.0.0

Make sure your local machine and Dockerfile satisfy this requirement. The build pipelines on jenkins have been updated to use node 24.19.0.

ChangeDetectionStrategy​

The Default Change Detection Strategy is now OnPush. Angular's change detection uses a more optimized approach by default called ChangeDetectionStrategy.OnPush. This strategy makes components only run change detection when:

1. An input or Signal variable changes (by reference).
2. An event originates from the component or its children.
3. ChangeDetectorRef.markForCheck() is called manually.

This means components with:

• variables might not update when the variable gets a new value.

protected asyncValue: string = "default value";

myService.getValue().subscribe((newValue) => {
  // OnPush won't trigger change detection for a local variable mutation.
  this.asyncValue = newValue; // Won't be updated in component's template
});

• functions in templates are not constantly being run anymore

// DOES NOT WORK AS EXPECTED
// Template: <p>{{ getFormattedName() }}</p>

name = 'Alex';

setTimeout(() => {
  this.name = 'Jordan';
  // getFormattedName() WILL NOT RE-RUN!
  // OnPush won't trigger change detection for a local variable mutation.
}, 1000);

getFormattedName() {
  return this.name.toUpperCase();
}

Fix:

• Use signals and computed signals to define variables
• Use previous behavior with ChangeDetectionStrategy.Eager (as a last resort)

Redundant Nullish Checks Trigger Compile Errors​

Angular’s strict template type-checker now flags unnecessary optional chaining (?.) or nullish coalescing (??) on non-nullable variables.

// Fails at compile time if `a` is guaranteed non-nullable
const result = a?.b;
const val = a ?? "default";

// Remove redundant operators
const result = a.b;
const val = a;

Optional Chaining Evaluates to undefined​

Short-circuited optional chaining expressions always evaluate to undefined (never null).

// Update strict equality checks expecting `null` to check for `undefined` instead, or use loose equality (`== null`) to catch both.
a?.b?.c === null // false
a?.b?.c === undefined // true
a?.b?.c == null // true

reportProgress deprecation​

The reportProgress field of HTTP requests has been deprecated and replaced by reportDownloadProgress and reportUploadProgress. Custom code that used this should migrate to the new fields.

baseUrl no longer allowed​

The baseUrl field is no longer allowed in the tsconfig.json. Custom paths in the tsconfig should be adjusted.

Data access​

This only affects projects using Angular, standard-api and have enabled the data access in Angular

Fixed incorrect mapping of canSeeUpdatePage, canSeeFilterPage, canSeeFetchPage, canSubmitUpdate, canSubmitFilter and canSubmitFetch in the LegacyMapperService expanders. Instead of mapping to update and fetch they will now map to modify and status. Applications that have configured data access to use update and fetch will have to update them to modify and status.

Custom branding​

• If the angularApp uses the angular.hasCustomBranding option, The following files have had code replaced by feature anchors as part of a fix.
  • branding-text-font in index.html
  • branding-icon-font in index.html
  • branding-sidebar in layout.component.scss

To migrate add back the following harvests in the corresponding files.

index.html:

-- anchor:custom-branding-icon-font:start
  <link rel="stylesheet" href="https://fonts.googleapis.com/css2?family=Material+Symbols+Outlined:opsz,wght,FILL,GRAD@20..48,100..700,0..1,-50..200"/>
-- anchor:custom-branding-icon-font:end
-- anchor:custom-branding-text-font:start
  <link rel="preconnect" href="https://fonts.googleapis.com">
  <link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
  <link href="https://fonts.googleapis.com/css2?family=Maven+Pro:wght@400;500;700&display=swap" rel="stylesheet">
-- anchor:custom-branding-text-font:end

layout.component.scss:

-- anchor:custom-branding-sidebar:start
    img {
      height: 100%;
      padding: 1.25rem 0 1.25rem 1.25rem;
      &.compact-mode {
        padding: 1.438rem 0 1.438rem 0.875rem;
      }
    }
-- anchor:custom-branding-sidebar:end

The following main things were added:

• OOTB menu: Menu items are now added by default, meaning the sidebar will not be empty anymore. However, if the default menu setup is not what you need, the menu does need to be created custom like before.
• Transmuter: There used to be a transmuter Upgrade to Angular Project on applications. This was reworked into transmuter Generate Default Angular App, helping you create an Angular model based on your existing elements model.
• Default Angular App initialization in project initializer: During project initialization an Angular app will now be included by default. You'll need to explicitly opt out if you don't want Angular.
• Support for base components: The OOTB Angular front-end includes CRUD pages for base components, so you don't have to use KO for this anymore.

These changes present themselves in two ways:

• OOTB Angular for a new project
• Adding an OOTB Angular frontend to an existing project

Scenario 1: New Projects with Angular App​

You can include Angular as a frontend when running the NS Initializer to set up a new project.

Prerequisites:

• Have Yarn installed on your computer. This is the preferred package manager within NSX, employees should consult the "Software required to install" discourse post to install Yarn correctly.
• Have version 7.0.0 of the NS Initializer installed.

Steps to follow:

1. Create an empty folder for your new project.
2. Initialize a project using:
   • Using µRadiant: Go to Initialize Project and choose "Application".
   • Using CLI: nsinit app.
   • In both cases, make sure to set Include Angular frontend? to true, as it will be by default.
3. Expand the application. You should see two folders in the /expansions directory: one for the backend with KO, and one for the Angular frontend.
4. Run yarn install in the expansions/{your-project-name}-angular directory. This installs the packages the Angular application depends on.
5. Build the frontend and backend using the scripts in /scripts.
6. Start the application by running the start_default_services.nss script. This will result in KO running on port 8080 and Angular on port 8081. The gateway runs on port 8082. It is the preferred entry point of the application and can be used to access both the Angular and KO frontend, e.g. localhost:8082 (Angular), localhost:8082/<jeeAppName> (KO).
7. Enter the username and password from the .credentials file to login. Make sure you add this file to your .gitignore.

You now have a Knockout and an Angular frontend for your application.

These steps are also included in your project's documentation under documentation/local_setup_guide.md.

Scenario 2: Adding an Angular frontend to an existing KO application​

A fully OOTB Angular application can be added as a frontend alongside an existing KO frontend. This process consists of two transmutation steps:

1. Adding the Angular model files
2. Adding the Angular application to your project setup.

1. Steps to add Angular model files:​

Angular applications have their own metamodel. A transmuter has been added that creates an Angular model based on your existing Elements model. The result of the transmuter will be default CRUD screens for all the data elements in your model, unless they have the angular.noViewLayer option.

Steps to run the Generate Default Angular App transmuter:

1. Add the following expansionResources to your expansionSettings.xml:
   • angular-beam
   • angular-stdapi-expanders
   • data-operations-bundle (optional, but recommended)

<!-- Use the specified versions or newer -->
<expansionResource>org.normalizedsystems.beam:angular-beam::1.0.0</expansionResource>
<expansionResource>net.democritus.angular.stdapi:angular-stdapi-expanders::4.0.0</expansionResource>
<expansionResource>net.democritus.bundles:data-operations-bundle::2.5.0</expansionResource>

2. Open µRadiant. If you already have it opened, you'll have to reload the project after adding the expansion resources.
3. Install version 1.4.1 or newer of the net-democritus-angular-plugin if you haven't already.
4. Click on your application and run the Generate Default Angular App transmuter.

Generate Default Angular App transmuter

To verify the transmuter worked correctly, you can compare the new Angular expansion in your expansionSettings.xml with the following snippet:

<expansions>
  ...
  <expansion>
    <target>your-app-name</target>
    <profile>Std API yarn Ln0x access</profile>
    <type>angularProjects::AngularApp</type>
  </expansion>
</expansions>

2. Steps to add Angular application to your docker setup:​

After adding the model files, the next step is to extend your project-setup so the Angular frontend can be deployed to an environment. The recommended way to set up the Angular application in docker is to add Artifacts and Services to your project-setup model. Since this project setup can be modelled, a second transmuter (Generate Angular Setup) was developed to incorporate the new Angular app.

1. Open μRadiant and select .nsproject in the project button in the left panel. This opens the project setup model.
2. Open the "expansion-settings" tab and make sure the project-expanders are at least on version 3.4.0. If not, you can change this in your /.nsproject/expansionSettings.xml.
3. In μRadiant, click on your project and run the Generate Angular Setup transmuter. This will create Services and Artifacts for the gateway and your Angular application.

Generate Angular Setup transmuter

4. Run the rejuvenate_nsproject_setup.nss script. New images will be created in your /docker folder, as well as some scripts in your /scripts folder.
5. Expand the application.
6. Add an empty yarn.lock file in expansions/..-angular if it doesn't exist yet. This file is required to install the packages defined in the package.json file that the Angular application depends on. You should harvest the yarn.lock file and include it in Git.
7. Run the build scripts.
8. Run the start_default_services.nss script. This will copy the built code to the docker/../deploy folder and run the application in docker containers, resulting in KO running on port 8080 and Angular on port 8081. The gateway runs on port 8082. It is the preferred entry point of the application and can be used to access both the Angular and KO frontend, e.g. localhost:8082 (Angular), localhost:8082/<jeeAppName> (KO).

Possible issues​

• Finders with a name that do not follow the naming convention cause compile errors in Angular.
• When a project has defined custom networks in the docker-compose.yaml file, the default gateway setup no longer works. The network alias has to be changed or a new network needs to be created in order for the gateway to find the necessary services.
• For the basic auth login process, the /account/account endpoint is called. If the user does not have access to this endpoint, you can change the value of the angular.basicAuth.enable option on AngularApp to any different endpoint that requires the user to be logged in.
• If you encounter an issue along the lines of All custom valueTypes should have a nativeType for angular:form-input, angular:detail-field, ... you can exclude the field from the view-layer, or change the type of the field.

• minimal-jee-beam:2.2.0
• standard-api-beam:2.0.0
• service-api-beam:1.3.0
• jee-backend-beam:1.0.0 (new)
• struts-api-beam:1.0.0 (new)
• knockout-frontend-beam:1.0.0 (new)

These releases mark a milestone in the modularization of the JEE-stack. For the first time it is possible to offer modular beams for frontend and control layer. Hence the introduction of jee-backend-beam, struts-api-beam and knockout-frontend-beam.

When upgrading please read the changelog for each individual beam. You can find them in their respective GitHub repositories.

Splitting beams​

For a long time, our primary JEE beam, the minimal-jee-beam, was a comprehensive package that included everything from the backend logic to the Struts 2 API and Knockout.js frontend. This made it easy to get started with a full-stack application, but with the arrival of API and frontend alternatives, it often forced developers to include technologies they didn't necessarily need.

By making the beams and underlying expansion resources more modular you have the option to leave some of these legacy technologies behind. This has benefits such as having fewer vulnerabilities, smaller artifacts and cleaner models.

The purpose of expander beams has always been to provide functional units to developers. Ideally these functional units are small so that they can be more easily maintained and updated. However, as functionality keeps getting added, eventually expanders beams become large enough that they can be split into smaller functional units. On the other hand some beams have always been a bit too large, encompassing a few too many concerns, such as the minimal-jee-beam, but it was not technically possible to split them yet. In both cases, at some point large beams will inevitably be split into smaller beams. In this case the minimal-jee-beam has been split into three distinct beams:

• jee-backend-beam: This is the core of your application: Maven skeleton, JPA data layer, EJB logic layer and JNDI proxy layer.
• struts-api-beam: Provides a full control layer implemented in Struts2. Including actions, interceptors, and the legacy web-based API.
• knockout-frontend-beam: Contains a full view layer implemented in Knockout.js UI.

When combined, these three beams will expand exactly the same application as the minimal-jee-beam. However it does not contain net.democritus:Expanders anymore which will have an impact if you include other expansion resources in your expansion.

Modularizing net.democritus::Expanders​

Splitting the minimal-jee-beam was no trivial feat. Many expansion resources needed to be updated (and many other still need to be updated), including the infamous net.democritus:Expanders. That has historically been an expansion resource which contained many expanders spanning over various technologies and concerns. Over the past years and months large efforts have been made to modularize the net.democritus:Expanders expansion resource. Modularizing the net.democritus:Expanders means that knockout and struts related expanders are isolated and split into different modules. Also the different layers in the JEE backend are split into modules. Each module results in an expansion resource that can be used independently.

Below is a simplified overview of how net.democritus:Expanders has changed in preparation for the new beam releases.

net.democritus.Expanders:9.3.0:

net.democritus.Expanders:9.4.0:

Problems with splitting beams​

This section shows common issues you are likely to encounter. It will be explained why they happen and how to best fix them. Note that you should not encounter any of these issues if you stay with the minimal-jee-beam.

Duplication of expanders​

When you split an expansion resource, the expanders within now exist in multiple expansion resources (in the old expansion resource, and the newly split off expansion resource). This means that if both the old expansion resource and the newly split expansion resource are present, some expanders will be duplicated. This can lead to expander features being injected twice. A similar thing happens when you rename an expansion resource. In the case of renaming an expansion resource the replace configuration can be used. The replace however is not sufficient when splitting an expansion resource. For example, the jee-proxy-logic-expanders replace the net.democritus:Expanders. This means that only the expanders from the jee-proxy-logic-expanders will be present. So expansion resources that depend on expanders from net.democritus:Expanders that are not in the jee-proxy-logic-expanders will throw an error on expansion.

To help solve the issues encountered while splitting beams and modularizing expansion resources, new guardrails were added. These new guardrails require expanders-maven-plugin:2026.1.0.

New guardrails:

• Resource version constraints
• Added modelVersion field to expansionSettings and expansionResource to provide better feedback when the configuration causes a mismatch.
• Added resolution tree information to ResolveResourcesResult. Use mvn expanders:dependency-tree to view this information.

Resource version constraint on Expanders:9.4.0​

When replacing the minimal-jee-beam with the new smaller beams, no beam is depending on net.democritus:Expanders anymore. This causes version conflicts when other expansion resources still require an older version of it.

[ERROR] Failed to execute goal net.democritus.maven.plugins:expanders-maven-plugin:2026.1.0:expand (default-cli) on project
project-factory: Execution default-cli of goal net.democritus.maven.plugins:expanders-maven-plugin:2026.1.0:expand failed:
ExpansionResource dependency resolution failed: 'net.democritus:jee-ear-packaging-expanders::9.5.0' requires
at least 'net.democritus:Expanders::9.4.0', but resolved version was '9.2.0'
[ERROR] Either upgrade 'net.democritus:Expanders' or remove it from the (transitive) dependencies.
[ERROR] Dependency Resolution Chains:
[ERROR]   - org.normalizedsystems.beam:jee-backend-beam::1.0.0
[ERROR]     '-> net.democritus:jee-ear-packaging-expanders::9.5.0
[ERROR]   - org.normalizedsystems:project-factory-expanders::1.10.0
[ERROR]     '-> net.democritus:Expanders::9.2.0

The easiest way, but not the preferred/recommended way to solve this issue is to add a dependency on Expanders:9.4.0. Either by updating the Expanders dependency in the project-factory-expanders or by adding Expanders:9.4.0 explicitly in the expansionSettings. Expanders:9.4.0 has been created as a backwards compatibility measure and so can be used this way. However as Expanders:9.4.0 still contains all submodules it is still monolithic preventing full modularization. So while this does solve the issue it is only a temporary solution and should ideally be avoided in favor of the better solution.

Instead of including Expanders:9.4.0 in some way, it is best to replace the dependency on Expanders completely. In the case of this example the project-factory-expanders need to remove the dependency on Expanders and replace it by one or more of the submodules (e.g. jee-proxy-logic-expanders, jee-ear-packaging-expanders, ...). Only the submodules that are actually necessary should be used.

Leaving out Struts or Knockout​

The new beams allow developers to leave out the knockout-frontend-beam and the struts-api-beam. Doing this on an existing application is in practice quite difficult.

This is because while the beams have been updated to be modular and make use of the symbiotic dependencies. Many other expansion resources do not. They often still depend on net.democritus:Expanders or don't make it possible to leave out some knockout related expanders. This makes it impossible to fully remove the struts and knockout technologies until these expansion resources have been updated.

If you do try to leave out a technology or refactor an expansion resource you might encounter the following error.

Exception in thread "main" net.democritus.elements.ElementNotFoundException: Cannot find Expander(ListHtmlExpander::net.democritus.expander.knockout.projection)

	at ExpanderFeatureTreeToComposite.fetchExpander (expander=<Expander ListHtmlExpander::net.democritus.expander.knockout.projection>)
	at ExpanderFeatureTreeToComposite.mapTree (tree=<ExpanderFeature >)
	at FeatureTreeToComposite.mapExpanderFeatures ()


	at net.democritus.expansion.ExpanderFeatureTreeToComposite.fetchExpander(ExpanderFeatureTreeToComposite.java:168)
	at net.democritus.expansion.ExpanderFeatureTreeToComposite.mapTree(ExpanderFeatureTreeToComposite.java:131)
	at net.democritus.expansion.FeatureTreeToComposite.mapExpanderFeatures(FeatureTreeToComposite.java:259)
	at net.democritus.expansion.FeatureTreeToComposite.mapTree(FeatureTreeToComposite.java:139)
	at net.democritus.expansion.ExpansionResourceTreeToComposite.mapFeatures(ExpansionResourceTreeToComposite.java:336)
	at net.democritus.expansion.ExpansionResourceTreeToComposite.mapTree(ExpansionResourceTreeToComposite.java:152)
	at net.democritus.model.resources.ExtractResourcesStep.convertExpansionResources(ExtractResourcesStep.java:162)
	at net.democritus.model.resources.ExtractResourcesStep.performStep(ExtractResourcesStep.java:40)
	at net.democritus.model.resources.ExtractResourcesStep.performStep(ExtractResourcesStep.java:27)
	at net.democritus.model.common.ModelLoader.performStep(ModelLoader.java:151)
	at net.democritus.model.common.ModelLoader.loadModel(ModelLoader.java:90)
	at net.democritus.model.common.ModelLoader.loadModel(ModelLoader.java:54)
	at net.democritus.tasks.ExpandTask.execute(ExpandTask.java:43)
	at net.democritus.runner.NsxPrimeRunner.executeLocalTask(NsxPrimeRunner.java:70)
	at net.democritus.runner.NsxPrimeRunner.main(NsxPrimeRunner.java:21)

In this case the knockout-frontend-beam was omitted from the expansionSettings. This means that ListHtmlExpander is not present so the expander feature cannot be injected into it which leads to this error. To solve this, expanders and expander features that depend on knockout (web-styles) should be isolated into a separate module (expansion resource) with a dependency on web-styles. This new expansion resource should then be included as a symbiotic dependency on the expansion resource it was isolated from. This will ensure that the new expansion resource will only be included if web-styles (knockout) is present in the expansion settings.

In this example web-styles is used, but the same can happen with other technologies and expansion resources, hence why it is important to make small modular expansion resources instead of monolithic expansion resources which combine different technologies and dependencies.

How to modularize an expansion resource​

Note: This modularization step is optional. It is only required for expansion resource maintainers that seek a truly modular application.

Typically, expansion resources provide an extension to the NSX JEE-stack. They contain expanders and expander features targeting various technologies that are present in the JEE-stack. In order to do this, they depend on net.democritus:Expanders, which covered most of the stack. As explained above, net.democritus:Expanders has now been modularized into distinct expansion resources that group expanders per technology.

To make use of this modularization in an application, all included expansion resources must be modularized as well. Below is a step-by-step guide on how to achieve this, based on an example scenario.

Example Scenario: CSV Expanders​

Suppose you have an expansion resource adding CSV download functionality. It is called csv-expanders, and it contains an integration with the Knockout frontend, the standard-api, and the Angular frontend.

Step 1: Create modular expansion resources​

The first step in creating a modular expansion resource is to create a sub-module for each technology you want to split off, and then move all relevant expanders into them.

Rename your root maven resource from csv-expanders to csv-expanders-project and create a submodule csv-expanders. This module will act as the entry point for your users (as it did before because we kept the name). Next, create a submodule for your core expanders and one for each technology you want to split off. Finally, move all the expanders, features and data resources to the correct module.

You might need to add a dependency from technology specific modules to the core module to inject features or use shared data resources.

After this step, your bundle module should not contains anything more then a pom.xml.

Step 2: Add symbiotic dependencies​

In this step, we will add the dynamic behavior. We only want to include technology-specific resources if the underlying technology is actually included in the application. This can be done using symbiotic dependencies.

Configure a symbiotic dependency in the bundle module (csv-expanders) for each of the modularized sub-modules. Base modules, such as csv-core-expanders, should always be present; therefore, their dependencies should not be symbiotic.

With this second step, we have now created an expansion resource that provides a feature with a set of core expanders that will always be present and optional support for a set of technologies. Using this architecture, expander maintainers can easily add support for more technologies while giving application builders the choice of what to include in their application.

As can be seen from the number of minor releases, nsx-metamodels is undergoing heavy construction work. This blogpost aims to clarify the reasoning behind the recent changes, the evolution of the metamodelling practice, and what is still ahead of us.

Please note that this post is quite the heavy read, but breaking down these complex concepts is necessary to explain where we are heading. It is primarily intended for those who have been working with metamodels, as well as anyone considering adopting them, with the objective of being informed of the process.

The most important terminology used in this post:

• Program
• ProgramType
• Module
• ModuleType
• M2 model: Refers to a meta-model, ontology or Domain Specific Language, specified in an M3.
• M1 model: Refers to an actual model, i.e., an instantiation of an M2 meta-model or ontology.

nsx-metamodels: a walk through the latest versions​

2026.2.0 - the <dependencies> system​

From nsx-metamodels 2025.15.0 until 2026.2.0, support for the <dependencies> system was developed.

Before 2025.15.0, it was not possible to add modules to an already existing ProgramType. If you wanted to add modules to a Program, you had to create an extra ProgramType to support those modules. A new ProgramType entailed its own custom ProgramFactory, which brought a whole new set of issues. The developed <dependencies> system allows you to add modules to a Program and its existing ProgramType without the significant amount of custom code needed before.

An explanation of this system using the messaging-metamodel example:

Messaging Ontology

MessagingJee Ontology

• messaging ontology: defines the standalone MessageSpecification module containing topics and schemas.
• messagingJee ontology: bridges elements and messaging. It defines MessageGroup (containing MessageProducers and MessageConsumers publishing/subscribing to topics) which has an extension reference to elements::Component. This allows a JEE application to contain multiple message groups.

On the M1 level, a jeeApplication (or the specific component) needs to be able to read the target MessageSpecification to relate its producers/consumers to actual topics and payloads. This is achieved via the <dependencies> system:

<component name="messageBus" type="elements::Component">
  <version>1.0.0</version>
  <fullName>messageBus</fullName>
  <dependencies>
    <dependency>
      <to>local::specifications/events/model/events.xml</to>
      <scope>expansion</scope>
    </dependency>
  </dependencies>
</component>

This way, the MessageBus component (a Module) can import the "events" specification and use its topics and schemas.

What was wrong with this <dependencies> system?​

The original <dependencies> system suffered from three main architectural shortcomings:

1. Tightly coupled to elements: Since the system was defined inside the elements ontology, creating a truly standalone metamodel was impossible without importing elements, defeating the goal of modularity.
2. Lack of transparency: the system was deeply buried within the elements core, making it obscure and difficult to understand. Besides, “dependency” is a highly overused term, lacking semantic meaning here.
3. Inability to depend on program: maybe most critically, the system could not resolve M1 level dependencies pointing to a Program. While an M2 reference to an ElementClass with a program role was possible, it failed to interpret on M1. This prevented us from creating a high level connection between two metamodels.

2026.3.0 - the Standalone Metamodel profile​

Enter version 2026.3.0. This was the first round of improvements on the nsx-metamodels to deal with both the issues encountered before the <dependencies> system, and the issues of the <dependencies> system itself.

When using 2026.3.0, the following matters are changed as a way of improving the concerns:

1. A standalone metamodel profile: A new profile was added to 2026.3.0: Standalone Metamodel. This profile is almost identical to Standard Metamodel 3. However, in this profile, the tag #meta.dependencyDeclaration was left out. This tag added an association reference to elements::Dependency on every Program and Module in the metamodel, enforcing an ontologyImport to elements. Thanks to this profile, a standalone metamodel is truly standalone.
2. Programs can now be referenced to, and depended on: This version allows you to depend on Programs from another ontology. To do so, you define the program as a ModuleType, and thus import it into your model as a module instead of a program. This way, you can reference from program & module to Program on M2 level, and actually resolve this reference on M1 level.

An example:

<dataResource type="expansionControl::ModuleType">
  <moduleType>
    <name>NodeBackend</name>
    <component>DoleComs</component>
    <programType>DoleComs::NodeProgram</programType>
    <expandableElement>elements::Application</expandableElement>
    <moduleFactory>net.democritus.elements.ApplicationModuleFactory</moduleFactory>
    <modelDirectory>$source.rootDirectory$/applications/$application.shortName$/model</modelDirectory>
    <sourceDirectory><!-- NO HARVEST --></sourceDirectory>
    <expansionDirectory><!-- NO EXPAND --></expansionDirectory>
    <scope>reference</scope>
  </moduleType>
</dataResource>

Here, we load elements::Application (a Program) as a Module into a different metamodel, with a different Program. And we can then use it like this:

<node>
  <name>MessagingNodeExample</name>
  <packageName>com.dolecoms.node</packageName>
  <sourceType>JAVA</sourceType>
  <dependencies>
    <dependency>
      <to>local::applications/jeeApp/model/jeeApp.xml</to>
      <scope>reference</scope>
    </dependency>
  </dependencies>
</node>

However, as you can see in the example, version 2026.3.0 still relies on the <dependencies> system to perform the imports on M1 level.

2026.4.0 - Introducing ModuleImports​

In the next version (2026.4.0) we introduce the ModuleImports. This mechanism improves the modularity of metamodels and the transparency of connecting modules. Module imports are defined on a Program or Module, and specify which other modules are required to make a Program or Module work. A technical deep dive on the topic can be found here.

Back to our MessageBus example, this is now changed to:

<component
    xmlns="https://schemas.normalizedsystems.org/xsd/elements/2025/14/0"
    moduleId="components/messageBus/model/messageBus"
    type="elements::Component">
  <import module="local::specifications/events/model/events.xml" scope="expansion"/>
  <name>messageBus</name>
  <version>1.0.0</version>
  <fullName>messageBus</fullName>
  <options>
    <configuration.properties/>
  </options>
</component>

Every import here specifies the import of a module, to be used in this module (a component called MessageBus). Here, dependencies are merely interchanged by module imports. However, we can now as well couple programs:

<node xmlns="https://schemas.normalizedsystems.org/xsd/DoleComs/1/2/0-SNAPSHOT">
 <import module="local::applications/jeeAppExample/model/jeeAppExample.xml" scope="reference"/>
 <name>EmsNode</name>
 <packageName>com.dolecoms.node</packageName>
 <sourceType>JAVA</sourceType>
</node>

The program Node imports the program Application, an import that used to be impossible.

What is to be expected? What is the final aim of these reworks?​

During these efforts to further modularize the metamodels and general project setups, we were able to identify the root cause of our pain points. Our tooling (µRadiant) thus far assumed a strong coupling between the functional and structural (or construction) information.

We consider the functional view to be the what, the system's operational behavior and functionality, i.e. our functional model (think data elements, task elements, etc.), whereas the construction view embodies the how, the system's physical structure and implementation (think expansions, layers, technologies, etc.).

The final aim of this effort is to decouple these two and create a truly modular way of project composition. In order to achieve this, some more sub-objectives need to be built on top of the groundwork we have laid in 2026.3.0 and 2026.4.0:

• Enable model loading without defining ProgramTypes or ModuleTypes, since these are only needed for expansion. With this, we can reference across modules and programs of various metamodels, and actually instantiate these references on M1 level without the technical worry of creating moduleTypes.
• Make Programs and Modules truly standalone blocks. We already don’t need the elements ontologyImport anymore, and they can already import one another using module imports. However, to establish its usability, µRadiant support is required.
• ExpansionSettings should be configurable parallel to the model, not as the root of it. There will be a duality of architecting the functional model, and designing the project / expansion composition.
• The core of our framework (prime-core) currently always includes the elements ontology. As we increase modularization internally we are making the necessary steps to eventually extract elements from our core and provide it as a separate building block.

What version should I be using now?​

We aim to provide a solid experience for these features, especially in our tools. While it is perfectly fine to use the latest release, you should know these new features (ModuleImports and importing Programs) are not yet fully supported in the µRadiant. So we recommend waiting to use these until the total effort is completed. The general advice would be to stick to the lowest version supporting the features you need.

However, in case these modular constructions are necessary, we ask you to tread carefully with the intermediate releases. Version 2026.4.0 does provide stable support for these new features, but lacks µRadiant support and requires some technical deliberation. Technical documentation can be found here.

Upgrade to Angular 21 and Angular Material 21​

For this release we updated all the code to Angular 21, in order to stay up to date with the releases and best practices.

Added DataProjection support​

A mechanism has been implemented to facilitate fetching of different DataProjections if the used control layer allows this (std-api). The defaults are set to details for getSingle calls and info for getList calls. This implementation also allows the use of calculated fields with the info projection now.

For the moment, the possible projections are set by a ModelLoadingListener that defaults to the info ($DataConnector$-table.model.ts) and details ($DataConnector$.model.ts) projections. In the future it will be possible to manually define other projections as well.

Added Finder support​

We have added a FinderConnector and QueryConnector that implements the new abstract FilterConnector. This allows to support finders as well as querysearch at the same time (depending on what control layer you are using).

The option hasSearchBar has also been ported. Like in KO this will expand a searchbar in the header of the list page connected to a finder defined by the specified value of the option.

Related to the addition of a universal Filter feature, previously only one querysearch was supported to be used as a filter. This has been changed to any amount of querysearches and finders.

Added Authorization support​

We have added AuthorizationRights to make certain parts of the application not accessible (used in guards, directives, services). These rights can be accessed through the ACTION_AUTHORIZATION_SOURCE InjectionToken, the interface can be provided by a control layer specific implementation, or you can provide your own. Some directives have been added to handle authorization on the most common used components

• ButtonAuthorizationDirective
• TableRowActionMenuAuthorizationDirective

These directives handle disabling components as well as showing tooltips on why it is disabled. You can look at these as examples when wanting to use the authorization feature somewhere else.

Added support for swapping out default add/edit with DataOperations​

Using the following tags you can now conditionally turn of some expanders:

• #angular.data-view.action.add.custom: disable default add page.
• #angular.data-view.action.edit.custom: disable default edit page.
• #angular.data-view.action.delete.custom: disable default delete dialog.
• #angular.data-view.routing.add.disable: disable the add route.
• #angular.data-view.routing.edit.disable: disable the edit route.
• Added feature anchors to remaining DataView actions (add, edit, delete, details, list).

Refactored use of HttpClient​

We have added an API specific HttpClient. This allows for easy changing of authentication headers, error handling etc. per different API implemented. The implicit behavior of the http interceptors is also now removed. To facilitate the removal of the use of interceptors a lot of operator functions that handled the logic of the interceptors have been created.

• handleDataAccessError
• handleAlertError
• handleDataAccessFormError
• notifyDataConnectorSuccessEvent
• notifyDataConnectorFailureEvent

Metamodel changes and additions​

Metamodel additions of abstract Connector and View. This allows for easier extension of different types of views (e.g. ListView, InstanceView, FilterView) or connectors (e.g. DataProjectionConnector, DataOperationConnector, ...).

Migration guide​

Beam usage​

Instead of individually defining the various angular expansion resources, please use the angular-beam. This is the way angular should be used. The beams are curated and tested thoroughly.

When using angular in combination with the standard-api as the control layer you should use the following.

<expansionResources>
  ...
  <expansionResource name="org.normalizedsystems.beam:angular-beam" version="0.2.0"/>
  <expansionResource name="net.democritus.angular.stdapi:angular-stdapi-expanders" version="3.6.2"/>
  <expansionResource name="org.normalizedsystems.beam:standard-api-beam" version="1.1.0"/>
</expansionResources>

When using angular in combination with the service-api as the control layer you should use the following.

<expansionResources>
  ...
  <expansionResource name="org.normalizedsystems.beam:angular-beam" version="0.2.0"/>
  <expansionResource name="net.democritus.angular.svcapi:angular-svcapi-expanders" version="3.6.1"/>
  <expansionResource name="org.normalizedsystems.beam:service-api-beam" version="1.2.0"/>
</expansionResources>

Upgrade to Angular 21​

Normally you shouldn't have any issues, you can look at the migration guide to see what changes in custom code need to be done.

Some notable changes are:

• We removed @angular/animations, this is being deprecated. However, if necessary it can be re-added as custom code in the package.json5 file and provided in the app.config.ts.
• Control flow syntax migration, Angular is planning on removing the ngIf, ngFor, ... directives in Angular 22. They deprecated them a while ago, so it is best to start switching to the control flow syntax.
• Lastly, we also upgraded to version 17.0.0 of ngx-translate. They deprecated some methodes and the direct calling of variables in their services. You can look at their migration guide for the preferred changes.

Jenkins pipeline​

Upgrade dependencies​

net.democritus:querysearch-expanders::3.5.1+ is required. Use any of the following or make sure the minimum required querysearch-expanders version is provided elsewhere.

• org.normalizedsystems.beam:service-api-beam::1.2.0+
• org.normalizedsystems.beam:standard-api-beam::1.1.0+

Metamodel changes​

Added DataProjection support​

A ListView element is automatically linked to a DataProjectionConnector for the info projection. If you want to change this back to the previous default of details, you can do this by using the option angular.legacy.table.useModelProjection. This option will stay in place until we move away for automatically defining the model with ModelLoadingListeners and start defining the model explicitly.

<options>
  <angular.legacy.table.useModelProjection/>
</options>

While upgrading it is possible that the newly used info projection does not contain some of the fields being called in custom code. You can either (1) add these fields to the info projection or (2) go back to the details projection. Often times you can rely on duck typing to handle it correctly, e.g. when needing only the id.

The option angular.isTableColumn has been removed together with the transmuter adding this to all the fields having the isInfoField attribute. The option is not necessary anymore because this is now handled by the info projection. A new transmuter has been added that removes this option everywhere and sets theisInfoField attribute to true.

The DataAccess interface has undergone some changes. The defaults allow for no breaking changes in the custom code. However, the %dataConnector%ListModel has been changed with a generic PaginatedList model from the ns-core runtime library. The expander for this model has also been removed.

getSingle({ id }: { id: string }): Observable<%dataConnector%Model>;
getList({ segmentParameters }: { segmentParameters?: %dataConnector%SegmentParameters }): Observable<%dataConnector%ListModel>;

getSingle<T extends keyof %dataConnector%Projection = '%dataConnector%'>({ id, projection }: { id: string, projection?: T }): Observable<%dataConnector%Projection[T]>;
getList<T extends keyof %dataConnector%Projection = '%dataConnector%'>({ segmentParameters, projection }: { segmentParameters?: %dataConnector%SegmentParameters, projection?: T }): Observable<PaginatedList<%dataConnector%Projection[T]>>;

To make the DataSource default to a certain projection, the InjectionToken for the DataSource needed to get a type. For this reason we moved the DataView related tokens to a different file DataView-view.tokens. Namely, a file expanded by DataView instead of DataConnector. Custom imports using these tokens will need to be updated. If you don't want change the imports in custom code right away, you can get the tokens back in the original place by using the option angular.legacy.tokens.

When you have a custom token defined, you should add the type now. This is necessary otherwise the DataSource cannot be used with multiple projections.

<options>
  <angular.legacy.tokens/>
</options>

Lastly, when using a *-data-access.service directly, the defaults of the used projection is not respected. This means that custom code will break, because now you need to define a projection. However, when using the correct *_DATA_ACCESS InjectionToken this is handled correctly. This will also allow to easily swap implementations later on. When running into this issue it is recommended to migrate to using the injection token instead of using the service directly.

Added Finder support​

To make the finders work together with querysearch, some things had to change.

1. The previous standard querysearch model (now filter) has been changed from an interface to a class. Any places in the code where object instancing is used to create a filter object needs to be changed to a new class instance using:

  const filter = new FooBarFilter();
  filter.foo = this.barService.getBarValue();

or wrapping the object in the fromObject() function expanded in the new class:

const filter = FooBarFilter.fromObject({obj: {foo: this.barService.getBarValue()}});

2. The token injecting the InfiniteDataSource used for populating the dropdowns in the forms has been changed from <...>FILTER_DATA_SOURCE to <...>FINDER_FILTER_DATA_SOURCE and <...>QUERY_FILTER_DATA_SOURCE for finders and queryssearches respectively.
3. When upgrading from a previous version your previously defined querysearch model file used will have been renamed from <...>Filters to <...>Filter resulting in possible breaking code in custom anchors. You can safely assume that changing <...>Filters to <...>Filter wil fix most issues in custom code and custom imports.
4. Some imports could have been removed/added from the expanded files resulting in missing/duplicate imports.
5. It could be possible that when a DataChild is defined in the model, and you do not have a valid field in the filter of the child pointing to the parent that code will be expanded that will not compile. If you run into this problem, add a field to your filter pointing to the parent.
6. The FilterOptions have been moved from being calculated in their FilterOptionResolver to being calculated directly in their respective FilterFormComponent(s). If you have any custom code on the list page interacting with filterOptions this will have to be moved to the FilterFormComponent(s)

Refactored use of HttpClient​

The use of angular interceptors have been removed and moved to the specific clients. When you use the generic angular httpClient the following will no longer occur

1. Error mapping (check if error from svc-api and map it to internal error structure)
2. Error handling (directly act on an error, e.g. 404)
3. File download error handling
4. Authentication header addition

Either change to the new expanded api specific HttpClient (preferred) or add these interceptors again as custom code while awaiting the refactor.

return this.httpClient
  .get<X>({url: url})
  .pipe(
    map((document) => this.xModelMapper.map(document))
  );

return this.httpClient
  .get<X>({url: url})
  .pipe(
    map((document) => this.xProjectionMapper.map({document})),
    handleDataAccessError({ injector: this.injector }),
    handleAlertError({ injector: this.injector })
  );

.get(url, {headers: headers, params: params})

get({url: url, options: options})

Some imports are no longer default expanded. These should be added custom if needed in *-data-access.service.ts.

• catchError
• AlertErrorModel
• throwError
• EMPTY
• tap
• filter

return this.httpClient.get(url, {
    params: params,
    observe: 'response',
    responseType: 'blob',
  });
}  

return this.httpClient.downloadFile({
    url,
    options
  }).pipe(
    filter(response => response.type == HttpEventType.Response),
    handleDataAccessError({ injector: this.injector }),
    handleAlertError({ injector: this.injector })
  );
}

create({ model }: { model: DemoElementModel }): Observable<{ id: string }> {
  let headers = new HttpHeaders();
  let data = this.demoElementCreateDocumentMapper.map({ model });
  // anchor:custom-create:start
  // anchor:custom-create:end
  return this.httpClient.post<{ id: string }>(url, data, {headers: headers}).pipe(
    map(response => ({id: response.id})),
    tap(response => {
      this.demoElementEventService.updateEvents({
        event: {
          objectIdentifier: response.id,
          type: 'create'
        }
      })
    }),
    catchError(error => {
      this.demoElementEventService.updateEvents({
        event: {
          objectIdentifier: '',
          type: 'create-failed'
        }
      });
      // anchor:custom-create-error:start
      // anchor:custom-create-error:end
      if (error instanceof AlertErrorModel) {
        this.alertErrorHandler.handleError({error: error});
        return EMPTY;
      }
      return throwError(() => error);
    })
  );
}
  

create({ model }: { model: DemoElementModel }): Observable<{ id: string }> {
  const url = '/v1/demoelements';
  const options: HttpClientOptions = {};
  let data = this.demoElementCreateDocumentMapper.map({ model });
  // anchor:custom-create:start
  // anchor:custom-create:end
  return this.httpClient.post<{ id: string }>({
    url: url,
    body: data,
    options: options
  }).pipe(
    map(response => ({id: response.id})),
    // @anchor:create-operators:start
    notifyDemoElementSuccessEvent({
      injector: this.injector,
      event: {
        type: 'create'
      }
    }),
    notifyDemoElementFailureEvent({
      injector: this.injector,
      event: {
        type: 'create-failed'
      }
    }),
    handleDataAccessFormError({ injector: this.injector }),
    handleDataAccessError({ injector: this.injector }),
    handleAlertError({ injector: this.injector })
    // @anchor:create-operators:end
  );
}

It is possible to add your own operator functions to the http-client by default. Define your own operator functions in the anchor:custom-methods of the http-client service or preferably in a separate class in the functions directory. Then register the operator function in the anchor:custom-default-operators within the #getDefaultOperators method.

• Custom error anchors have been removed from data access services. Use the existing error mapping classes or add an operator function to the http-client.

• Removed error-mapper.interceptor.ts and error.interceptor.ts. Use the existing error mapping classes or add an operator function to the http-client.

A breaking change has been introduced in the event.model.ts interface where the objectIdentifier attribute has been made optional. This potentially results in some custom code changes to handle the possible undefined nature.

Changed default filtering in dropdowns​

Dropdowns (nsc-select components) are no longer searchable by default. You have to add the option angular.defaultQueryFilter to a QuerySearch to make a data element searchable in the dropdown. This change allows you to choose the filter that is used for filtering the results in the dropdown.

There is a transmuter which will add this option for you to all querysearches, this will make all the dropdowns work as before. However just as before, if the filter is not implemented the filtering will not work. It is therefore recommended to carefully inspect the changes made by the transmuter and make changes accordingly.

<options>
  <angular.defaultQueryFilter/>
</options>

Module-metamodel absorbed in prime-core​

If your project started using the module-metamodel to declare dependencies between specific FeatureModules, you should refactor how these dependencies are defined. The module-metamodel has been absorbed in prime-core and received a new way of declaration.

1. First of, you can remove the angularAppModules.xml file.
2. In your angular-app.xml you should change the <featureModules> attribute with <dependencies>.
3. Add a type to your featureModule.xml.

<angularApp xmlns="https://schemas.normalizedsystems.org/xsd/angularProjects/7/0/0">
  <name>space-app</name>
  <featureModules>
    <featureModule>demo</featureModule>
  </featureModules>
</angularApp>

<featureModule xmlns="https://schemas.normalizedsystems.org/xsd/angularProjects/7/0/0">
  <name>demo</name>
</featureModule>
    

<angularApp xmlns="https://schemas.normalizedsystems.org/xsd/angularProjects/7/0/0">
  <name>space-app</name>
  <dependencies>
    <dependency>
      <to>local::angular/featureModules/demo/model/demo</to>
      <scope>expansion</scope>
    </dependency>
  </dependencies>
</angularApp>

<featureModule type="angularProjects::FeatureModule" xmlns="https://schemas.normalizedsystems.org/xsd/angularProjects/7/0/0">
  <name>demo</name>
</featureModule>
    

project
├── conf
├── applications
├── angular
.   ├── angularApps
    .   ├── space-app
    .   .   ├── model
    .       .   └── space-app.xml
    .       .
    .       └── angularAppModules.xml (to be removed)
    ├── featureModules
    .   ├── demo
    .   .   ├── model
    .       .   └── demo.xml

Other​

Here is a list of other issues you may encounter during the migration.

• Some expanded variables are declared with ? instead of !. Custom code using these variables might need to be adapted to handle undefined values.

• The variable filterOptions in -form.component.ts files has been updated to be a signal. Call the variable as filterOptions().

• The variable <dataElement>FilterDataSource in -form.component.ts files has been renamed to <dataElement>QueryFilterDataSource.

• When changing to a profile that enables the data access, you should include the angular.legacy.authorization option on the AngularApp. This will make it so the data access rights defined in the Account component are used.

• <dataElement>.guard.ts files are no longer expanded. The logic of these file is now implemented in the <dataElement>-filter-coordinator.directive.ts files.

• <dataElement>.filters.ts files have been removed. Custom imports need to be changed to use <dataElement>-filters.model.

Model schema adjustments​

DataOperations were originally designed as an abstract type to support extending the schema. After implementing many different types already, we have seen this was never really needed. Abstract types impose some restrictions in our tooling which led to the decision to implement types as a field instead. This gives us three clear advantages:

• It is easy to switch between different types throughout our tooling.
• It is easier to migrate from DataCommands to a Custom operation first, before switching to a more appropriate type later.
• It is much easier to define new types in an expansionResource, without the need for your own Metamodel.

<dataOperation type="operations::CreateOperation">
  <name>register</name>
  <parameterGroups>
    ...
  </parameterGroups>
</dataOperation>

<dataOperation>
  <type>Create</type>
  <name>register</name>
  <parameterGroups>
    ...
  </parameterGroups>
</dataOperation>

Simplified parameter types​

Previously we had ValueFieldParameter to refer to valueFields and AssociationParameter to refer to linkFields. This would sometimes be confusing from the perspective of the model. To simplify this a bit the new situation is as follows:

• FieldParameter with a field reference for both value and linkFields.
• AssociationParameter with a dataElement reference for references without corresponding field. (New)
• Deprecated ValueFieldParameter.
• Deprecated field reference on AssociationParameter.

Angular Expanders upgrade​

In version angular-expanders 7.0.0 the ui model has enabled abstract compositions for both the DataView and DataConnector. Previously data-operation connectors, forms and actions were modeled as extensions. These have also been changed to implement these abstract types instead.

As a result they will show up differently in the model files. Instead of a separate file for each connector or view, they will now be inlined in the file of their parent.

<!-- featureModules/country/model/dataViews/City.xml -->
<dataView xmlns="https://schemas.normalizedsystems.org/xsd/angularProjects/6/0/0">
  <name>City</name>
  <dataConnector>country::City</dataConnector>
</dataView>
<!-- featureModules/country/model/dataViews/City/DataOperationForms/Add.xml -->
<dataOperationForm xmlns="https://schemas.normalizedsystems.org/xsd/operationsAngular/2">
  <name>Add</name>
  <connector>country::City::register</connector>
</dataOperationForm>
<!-- featureModules/country/model/dataViews/City/DataOperationActions/Add.xml -->
<dataOperationAction xmlns="https://schemas.normalizedsystems.org/xsd/operationsAngular/2">
  <name>Add</name>
  <connector>country::City::register</connector>
  <dialog>form-page</dialog>
  <form>country::City::Add</form>
  <roles>
    <role>add-action-button</role>
  </roles>
</dataOperationAction>

<!-- featureModules/country/model/dataViews/City.xml -->
<dataView
    xmlns="https://schemas.normalizedsystems.org/xsd/angularProjects/7/0/0"
    xmlns:oa="https://schemas.normalizedsystems.org/xsd/operationsAngular/3"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <name>City</name>
  <dataConnector>country::City</dataConnector>
  <views>
    <view type="operationsAngular::DataOperationForm" xsi:type="oa:dataOperationForm">
      <oa:name>Add</oa:name>
      <oa:connector>country::City::register</oa:connector>
    </view>
    <view type="operationsAngular::DataOperationAction" xsi:type="oa:dataOperationAction">
      <oa:name>Add</oa:name>
      <oa:connector>country::City::register</oa:connector>
      <oa:dialog>form-page</oa:dialog>
      <oa:form>country::City::Add</oa:form>
      <oa:roles>
        <oa:role>add-action-button</oa:role>
      </oa:roles>
    </view>
  </views>
</dataView>

Migration guide​

Since the model files have changed, it is advised to do migration when you don't have many open PR changes to minimize merge conflicts.

The first step is to add the new version of the bundle to your expansionSettings:

<expansionResources>
  <expansionResource>net.democritus.bundles:data-operations-bundle::2.0.2</expansionResource>
</expansionResources>

Note: Also make sure your expanders-maven-plugin and/or micro-radiant are up-to-date to avoid any version issues.

Migrating Data Operations​

The migration happens when loading the model. This means you will be able to expand your application just fine. To persist the changes your best option is to run the following transmutation:

Migrating Data Operations Angular​

The migration of angular views is mostly just a rewrite of the model as well. The transmuter below will also clean up the previously used extensions:

Some inputs have been removed from the form components. If you used the form components with an <element>Model as input, you will now first have to convert the model to a dataOperation model using the <DataOperation>ModelMapper service! Most usages of the form component should be in expanded code however which won't need any changes.

Upgrading MR plugin​

To load and edit the new model files with MicroRadiant, you will need to get the latest plugin for data-operations.

That should be all, happy coding!

The new file format simply adds a name attribute to the root element. This attribute indicates the name that will be used for the file of the generated SQL script. The name should also equal the filename.

<dataInstances
    xmlns="https://schemas.normalizedsystems.org/xsd/sql-expanders/5/0/0/dataInstances"
    name="001-app-init-data">
  <!-- data instances here -->
</dataInstances>

Migration​

Once you upgrade the version of sql-expanders to 5.0.0 or above, the next time you export the application model from micro-radiant, it will move the existing init data file and update the file to the latest format. This is now possible because the model is aware of the init data file, represented as an ApplicationData meta element.

Do note that at this time it is not possible to modify the data in the micro-radiant, as it is not represented by a full NS model.

Releases​

At this time, the full support for Jakarta EE is not yet available in beam releases. For migrating expanders and testing until the time that these releases make it into the beams, we've provided developer previews that mirror the beams, but contain the latest versions of all expansion resources.

Preparing your expander project​

Expander projects may require some updates if they expand code with javax imports. The first step would be to migrate those specific expanders to the new imports system.

When moving the imports to the mapping file, they should be redefined as the new jakarta imports. The imports as defined in the mapping should be considered the optional/default case:

<?xml version="1.0" encoding="UTF-8" ?>
<mapping xmlns="https://schemas.normalizedsystems.org/xsd/expanders/2025/0/0/mapping" strict="true">
  <artifact this="dataElement.packageName + '.' + dataElement.name + 'ImportantBean'" importStrategy="java"/>

  <uses eval="'jakarta.servlet.http.HttpServletRequest'"/>
  <uses eval="'jakarta.servlet.http.HttpServletResponse'"/>
</mapping>

In addition, it will be required to add a technology lexicon to map the imports back to the old javax equivalent. This in essence allows you to define how the imports should be rewritten if a specific technology is active in the model. Note that these are defined as data resources and will be inherited from dependencies. Many imports may already remap automatically if you depend on a resource such as Expanders that had its own technology lexicon.

<dataResource type="expansionControl::TechnologyLexicon">
<technologyLexicon>
  <technology name="JAVA_EE"/>
  <coordinateRedirections>
    <coordinateRedirection>
      <coordinate>jakarta.servlet.http.HttpServletRequest</coordinate>
      <target>javax.servlet.http.HttpServletRequest</target>
    </coordinateRedirection>
    <coordinateRedirection>
      <coordinate>jakarta.servlet.http.HttpServletResponse</coordinate>
      <target>javax.servlet.http.HttpServletResponse</target>
    </coordinateRedirection>
  </coordinateRedirections>
</technologyLexicon>
</dataResource>

Migrating applications​

When migrating applications there are only two important steps:

1. Updating the settings of the project to target Jakarta.
2. Migrate custom code in harvests and ext files if needed.

Updating project settings​

1. Upgrade your expansion settings (typically in conf/expansionSettings.conf) to use versions of expansion resources that support Jakarta EE.

2. In the technical infrastructure settings, the JEE version should be updated to 10:

   Java 21.xml

   <technicalInfrastructure name="Java 21">
     <javaVersion>jdk21</javaVersion>
     <jeeVersion>10</jeeVersion>
   </technicalInfrastructure>
   

3. Add the hibernate.version option with value 6 to your Application model.

   myapplication.xml

   <application name="myapplication">
     <shortName>myapplication</shortName>
     <version>1.0.0</version>
     <components>
       <component name="account"/>
       <component name="assets"/>
       <component name="utils"/>
       <component name="validation"/>
       <component name="workflow"/>
       <component name="applicationStuff"/>
     </components>
     <options>
       <hibernate.version>6</hibernate.version>
     </options>
   </application>
   

4. Update the TomEE base image for Docker to a TomEE 10 variant. The latest version can be found on the documentation page for the base image. Today, this is:

   • docker.normalizedsystems.org/nsx-tomee-base:10.1.2-3.11.1 for root-based images
   • docker.normalizedsystems.org/nsx-tomee-base:10.1.2-3.11.1-rootless for rootless images

Migrating custom code​

Most custom code will be compatible with Jakarta EE already and will not require any changes. The majority of required changes will be the package names that changed from javax.* to jakarta.*. These are easy to identify once you migrate the project settings and expand, as those imports will no longer be found. This is solved by simply replacing import javax. with import jakarta..

Java 25 at runtime​

TomEE 8 was not compatible with Java 25 due to the removal of the SecurityManager in Java 24 (deprecated in Java 17). A workaround for this issue was added in version 10.2.1 of TomEE. We've now also backported this change to version 8 in our fork of TomEE 8 and released it as part of our TomEE 8.0.19 update.

For now our images will still default to Java 21, but by adding the jre25 modifier to the image tags, you can already make use of the latest LTS version of Java.

Today, this is:

• docker.normalizedsystems.org/nsx-tomee-base:8.0.19-3.11.1-jre25 for root-based images
• docker.normalizedsystems.org/nsx-tomee-base:8.0.19-3.11.1-jre25-rootless for rootless images

For the latest version of the image, please refer to the image documentation page.

Compiling for Java 25​

To compile for Java 25 and use its language features, you need to change the Java version in the technical infrastructure settings file of your JEE project. Ideally you would also make a new settings file as the name of the settings is typically the version of Java. If you make a new file with a new name, also update the technicalInfrastructure reference in your application instance.

<technicalInfrastructure name="Java 25">
  <javaVersion>jdk25</javaVersion>
  <jeeVersion>8</jeeVersion>
</technicalInfrastructure>

<applicationInstance name="my-application">
  <shortName>my-application</shortName>
  <version>1.0.0</version>
  <globalOptionSettings name="3.0 Modern"/>
  <presentationSettings name="3.1 Future"/>
  <businessLogicSettings name="TomEE Postgres Hibernate"/>
  <technicalInfrastructure name="Java 25"/>
</applicationInstance>

In addition to this change, you need at least version 9.1.0 of net.democritus:Expanders in your project to target Java 25.

You can get started by adding the bundle:

<expansionResources>
  <expansionResource name="net.democritus:data-operations-bundle" version="1.1.0"/>
</expansionResources>

Please note data-commands will not be deprecated and can remain to be used. Data-operations provide a more expressive model and improvements to the runtime so we do recommend switching, but this is not a requirement. If you want to migrate, the decision tree below will help you with deciding which type of Operation is the best replacement for a data-command.

Command Decision Tree​

Module-metamodel support​

In this version a dependency to the module-metamodel has been added. This allows for easy declaration of dependencies between modules, which are in this case FeatureModules.

Why would you want to declare dependencies between different FeatureModules?​

For example, you have a common FeatureModule that declares some DataConnectors and another FeatureModule containing DataViews that want to reuse already declared DataConnectors. When there is no possibility to declare dependencies between them, the expansion becomes unreliable. After explicitly defining the dependencies, the expansion will always make sure that the correct resources are loaded at the right time.

In order to get this to work you should add a angularAppModules.xml file to your project.

project
├── conf
├── applications
├── angular
.   ├── angularApps
    .   ├── space-app
        .   ├── model
            .   └── space-app.xml
            .
            └── angularAppModules.xml

<programModules xmlns="https://schemas.normalizedsystems.org/xsd/modules/1">
  <modules>
    <module>
      <moduleId>featureModules::api</moduleId>
      <moduleType>angularProjects::FeatureModule</moduleType>
    </module>
    <module>
      <moduleId>featureModules::geo</moduleId>
      <moduleType>angularProjects::FeatureModule</moduleType>
      <dependencies>
        <dependency>featureModules::api</dependency>
      </dependencies>
    </module>
    <module>
      <moduleId>featureModules::transport</moduleId>
      <moduleType>angularProjects::FeatureModule</moduleType>
      <dependencies>
        <dependency>featureModules::api</dependency>
      </dependencies>
    </module>
  </modules>
</programModules>

You are not required to add all FeatureModules here, only if you want to indicate some dependencies.

See the modules-metamodel repo for more information.

Breaking change for Struts2​

With this release of Expanders, we support both Struts2 6.x and 7.x to match the different versions of JEE. Since Struts2 completely removed support for the fileUpload interceptor in version 7, we've now also removed it from our application stack. The reasoning behind this decision is that this interceptor was responsible for CVE-2024-53677, which has a score of 9.5 on the CVSS 4 scale. The alternative implementation using the actionFileUpload interceptor has been implemented across all of our expanders for several months now, but custom upload actions will also have to be refactored to switch to the new system. Regrettably, the impact of this change will not be visible at compile time, so care must be taking when upgrading to version 9 of Expanders.

• NIST listing: https://nvd.nist.gov/vuln/detail/CVE-2024-53677
• Sonatype article: https://www.sonatype.com/blog/cve-2024-53677-a-critical-file-upload-vulnerability-in-apache-struts2

Migration​

The migration is fairly straight-forward and is described in this migration guide from Struts2: https://struts.apache.org/core-developers/action-file-upload-interceptor

An action that handles uploads should be modified by implementing the UploadedFilesAware interface. With this interface comes a method withUploadedFiles() that should be implemented. To retain backwards compatibility with existing implementations, it is possible to set the values of existing fields in the class from this method, which were previously set dynamically by the old interceptor using reflection.

public class AssetUploader extends ActionSupport {

  private File uploadData; // the actual file
  private String uploadDataContentType; // the content type of the file
  private String uploadDataFileName; // the uploaded file name

public class AssetUploader extends ActionSupport implements UploadedFilesAware {

  private File uploadData; // the actual file
  private String uploadDataContentType; // the content type of the file
  private String uploadDataFileName; // the uploaded file name

  @Override
  public void withUploadedFiles(List<UploadedFile> uploadedFiles) {
    if (!uploadedFiles.isEmpty()) {
      final UploadedFile uploadedFile = uploadedFiles.get(0);
      this.uploadData = new File(uploadedFile.getAbsolutePath());
      this.uploadDataContentType = uploadedFile.getContentType();
      this.uploadDataFileName = uploadedFile.getOriginalName();
    }
  }

There are also various improvements to better handle errors and reduce the number of synchronization issues.

Changes and improvements​

Glint​

The glint runtime is now packaged as part of a dedicated plugin. New releases are now available to the users as plugin updates.

Errors​

• Improved the representation of errors that cause the project loading to fail, such as missing Components or invalid expansion-resources.
• There was an issue that caused the project to get stuck in loading when an expansion-resources could not be found. This now shows an decent error message.
• Fixed bug causing error messages to appear as [Object object].
• Improved handling on newlines in error detail.
• Fixed issue where a missing Component would be shown as an unknown error.

Synchronization​

• Fixed issue where changes to nested elements, like ValueField in Field would not cause a model update. This had the unfortunate effect of these changes not being exported.
• Fixed issue where the model server would report changes to properties not known by the plugins, causing the plugin to get confused.
• Fixed issue in select-multiple-field where removing an option did not cause any updates.
• Fixed error in serialization breaking on an undefined value.
• Fixed issue when selecting a ValueFieldType that cleared the ValueField instead.
• Fixed issue where a SimpleValueType would contain too many NativeTypes when first created.
• Fixed issue where the last item of a list could not be removed.

Diagrams​

• DataElement diagrams are now updated when making changes instead of needing a refresh.
• Improved zoom behaviour of class diagrams to better respond to changes, in line with the state diagrams.
• Added search field for classes in the class diagrams. The graph will zoom in on the class if there is a single match.
• Fixed marker on aggregation edges.

Miscellaneous​

• Imported modules, such as the base-components, are now readonly. You will not be able to perform actions and form fields are replaced with static text.

Migration​

Upgrading MR plugin​

• Update the mr-plugin-expanders to 5.0.0 or newer.
• Change the profile in expansionSettings.xml to NSX Plugin 4 or Standard Plugin 4. With this, the plugin will now target MR v4 and cannot be used in earlier versions.
• Add the following expansion-resource:

  <expansionResource name="net.democritus.editor:mr-plugin-glint" version="2.6.2"/>
  

The glint expansion-resource can be updated to new releases to make use of new API's.

Metamodel improvements​

nsx-metamodel-stack v2025.8.0 has features to define formatting and required attributes. These will generate model validations. In addition, the mr-plugin-expanders will add field validations to the forms.

Ln0x support​

Previously only Ln02 link fields were supported, this has been extended to the full range of Ln0x that is implemented by the chosen control layer (std-api or svc-api). This behaviour is locked behind a profile for backwards compatibility reasons:

• Std API Ln0x
• Std API yarn Ln0x
• Svc API Ln0x
• Svc API yarn Ln0x

New number field component​

A new number field component has been introduced that handles text input in the fields more gracefully. The component also implements some fraction digits validators, adding more functionality. The component is powered by an I18N number formatter that handles fraction separators and number bounds correctly. Default this is set to the locale en-GB. For Dutch formatting use nl-BE in the app.config.ts.

• String interpolation
• Strict mode to catch errors in mapping.xml
• New list mapping syntax
• Improved stack-traces
• Support for extending the context of artifact paths, mapping files etc.

String interpolation​

String interpolation support in OGNL expressions for compact String creation.

<value name="path" eval="format('${component.name}/${component.version}')"/>

Strict mapping​

Mapping file can use 'strict' mapping, which fails when using a variable that is not bound.

<mapping xmlns="https://schemas.normalizedsystems.org/xsd/expanders/2025/0/0/mapping"
         strict="true">
  <!-- Fails because typo refers to a non-existing variable. -->
  <let name="dataElements" eval="componnet.dataElements"/>

New list mapping syntax​

<list name="valueFields">
  <!-- for-each element replaces attributes in the header -->
  <foreach name="dataElement" in="component.dataElements"/>
  <foreach name="field" in="dataElement.fields"/>
  <value name="field" eval="field.name"/>
  <!-- Sort item by a specific value -->
  <sorted eval="field.name"/>
</list>

<list name="names">
  <!-- Add a single item -->
  <item>
    <value name="name" eval="component.name"/>
  </item>
  <!-- Combine multiple lists -->
  <items>
    <foreach name="dataElement" in="component.dataElements"/>
    <value name="name" eval="dataElement.name"/>
  </items>
  <items>
    <foreach name="taskElement" in="component.taskElements"/>
    <value name="name" eval="taskElement.name"/>
  </items>
</list>

See more

Improved stack-traces​

Stack-traces of errors in the Expanders have been reworked to be more legible and provide more information.

net.democritus.expansion.mapping.PropertyMappingException: Encountered error trying to resolve Value<field>
	at expression 'fild.name'
	at <value name="field"> .(builder-test-mapping-syntax-25.0.xml:14)
	at <list name="valueFields"> .(builder-test-mapping-syntax-25.0.xml:8)
	at <mapping> .(builder-test-mapping-syntax-25.0.xml:2)
Bound variables {
	/* for-each field in dataElement.fields .(builder-test-mapping-syntax-25.0.xml:10) */
	field, __item = FieldComposite{testComp::Country::countryCode}
	/* for-each dataElement in dataElements .(builder-test-mapping-syntax-25.0.xml:9) */
	dataElement, __item = DataElementComposite{testComp::Country}
	/* let dataElements = component.dataElements .(builder-test-mapping-syntax-25.0.xml:4) */
	dataElements = [DataElementComposite{testComp::City}, DataElementComposite{testComp::Country}]
	component = ComponentComposite{testComp}
}

	at net.democritus.expansion.mapping.ognl.Evaluate.getValue(Evaluate.java:37)
	at net.democritus.expansion.mapping.ognl.Evaluate.getValue(Evaluate.java:43)
	...

Adding Variables to the mapping context​

If the default variables exposed to the Expanders, like artifactSubFolders, don't do the trick, it is now possible to define additional variable bindings.

Expander Variables

• Artifact id has changed to mr-plugin-expanders (see migration guide below).
• Makes use of new descriptions fields on ElementClass and References to add these descriptions as hints in the plugin.

See Changelog for the full list of changes.

Migration guide​

New artifact id​

In 4.0.0, the artifactId of the plugin expanders changes:

<expansionResource name="net.democritus.editor:editor-model-expanders" version="3.9.0"/>

to

<expansionResource name="net.democritus.editor:mr-plugin-expanders" version="4.0.0"/>

Upgrade to Angular 19 and Angular Material 19​

For this release we updated all the code to Angular 19, in order to stay up to date with the releases and best practices.

Separation of QuerySearch​

QuerySearch is now an addon, instead of the default filtering implementation. Everything related to filtering in the code has been moved to separate expansionResources, namely angular-querysearch-expanders, angular-svcapi-querysearch-expanders and angular-stdapi-querysearch-expanders. When these expansionResources are not added the application will still function, however the filtering capabilities will not be present. From now on you can also add filtering implementations, e.g. finders, or provide a custom one.

Yarn support​

We provide a solution to substitute npm with yarn if wanted. This drastically improves dependencies install times. Substitute the Std API profile with Std API yarn (or Svc) in your expansionSettings.xml.

Harvest expanders​

The angular-expanders now depend on the harvest-expanders:1.0.0, this is an example of one of the first expansionResources that contains reusable expanders. These expanders and expansion steps define the gen/ext less harvesting.

New design implementation​

This version contains the new designs made for the list and details page.

Migration guide​

Upgrade to Angular 19​

Normally you shouldn't have any issues, you can look at the migration guide to see what changes in custom code need to be done. The directive option standalone = true has become default, so you can remove this in your custom code if you prefer.

To stay up to date with Angular best practices, we removed the modules and made all the components standalone. This potentially requires some harvest code relocation:

• Declared providers in app.module.ts should be moved to app.config.ts.
• Declared routes in app-routing.module.ts should be moved to app.routes.ts. Instead of loading the module file, you should now lazy load the routes file.
• FeatureModule modules are removed.
• Declared routes in ${FeatureModule}-routing.module.ts should be moved to ${FeatureModule}.routes.ts.
• DataView modules are removed. However, the routing module has stayed. This is needed for DataChildren. If you declared providers in ${DataView}.module.ts, you should move these to ${DataView}-routing.module.ts.
• The core module has been removed, because all components are standalone. This can be re-added custom if needed.
• The shared module has been removed, because all components are moved to ngx-ns-runtime and otherwise they would be standalone. This can be re-added custom if needed.

Separation of QuerySearch​

To have the application function as before you will need to add following expansionResources:

• angular-querysearch-expanders:6.0.0
• angular-svcapi-querysearch-expanders:2.0.0 or angular-stdapi-querysearch-expanders:2.0.0

Yarn support​

You will probably need to install yarn on your machine first to make this work. You should do this via corepack: npm install -g corepack. After first expansion, you will potentially need to create an empty yarn.lock file, in your expansion folder. Then you can yarn and yarn start to install and start the application.

npmScopes:
  nsx:
    npmAlwaysAuth: true
    npmAuthToken: <yourTokenHere (same as in .npmrc)>
    npmRegistryServer: <registryServerHere (same as in .npmrc)>

Harvest expanders​

• You should move ext code of the AngularApp to a folder src, except the package-lock.json file and other root level files. Otherwise it will expand to the wrong place.
• If you have other root level files in your project, e.g. .npmrc, you should at this to the custom anchors of the .harvestInclude file, otherwise it will be ignored for harvesting.

New design implementation​

• Details page has been renamed to details-page from details and has been completely changed to fit the static formless design. You need to rename your harvest files and folders to include the -page part.
• A details component has been added that is used for the details-page as for the new inspect functionality on the list-page. The old implementation can be kept as ext to gradually change if wanted. However, we removed the nsx-datepicker and nsx-yes-no-toggle components form the shared module. These need to be re-added custom as well then.
• List page has been renamed to list-page from list. You need to rename your harvest files and folders to include the -page part.
• The list page has been changed to use the new button implementation and also includes an inspect feature to get an overview of the details. There are only visual breaking changes here, custom code should still function.
• Removed changes and destroy anchors, this needs to be moved to the methods anchor.
• Refactor of all the buttons in the application to nsc-button, also removed the theme include of the material.button. This should be re-added as harvest code if needed.
• Titles of details and list page are now translated completely.
• Moved dialog.service to ngx-ns-core as well as the ConfirmationDialog component. Custom code should switch to this implementation.

Data-access.service​

In the data-access.service files, the name of the old "generic" segmentParameterMapper is changed to a element specific one, usage of this mapper in custom code needs to be updated.

Removed legacy forms​

The legacy forms are no longer supported and you should update to the new form structure.

@nsx/ngx-ns-core​

• CSS variables name-change in sidebar:

--nsc-sidebar-menu-custom-return-header-background-color
--nsc-sidebar-menu-custom-return-header-background-color-hover
--nsc-sidebar-menu-custom-return-header-color

--nsc-sidebar-menu-custom-single-level-return-icon-background-color
--nsc-sidebar-menu-custom-single-level-return-icon-hover-background-color
--nsc-sidebar-menu-custom-single-level-return-icon-fill-color

• searchKey attribute has been removed from <nsc-select> components, this needs to be removed in custom html. Filtering has been moved to the dataSource implementation for the select components.

With prime-core 2025.0.0, expansion-resources can define symbiotic dependencies. These dependencies are not included automatically, but only in case a number of other expansion-resources are present. This allows expander developers to create resources that provide integration with other expander beams.

How it works​

Several expander projects have 1 goal, but multiple expansion-resources. This setup exists to support integration with specific use-cases without introducing hard dependencies.

E.g. enum-type-expanders has separate resources for integration with angular and rest.

• net.democritus.experimental.enumtypes:enum-type-expanders
• net.democritus.experimental.enumtypes:enum-type-rest-expanders
• net.democritus.experimental.enumtypes:enum-type-angular-expanders

However, this means that the expansionSettings become more complex:

<expansionSettings>
  <expansionResources>
    <expansionResource name="net.democritus:angular-svcapi-stack" version="1.4.0"/>
    <expansionResource name="net.democritus.experimental.enumtypes:enum-type-expanders" version="0.4.2"/>
    <expansionResource name="net.democritus.experimental.enumtypes:enum-type-rest-expanders" version="0.4.2"/>
    <expansionResource name="net.democritus.experimental.enumtypes:enum-type-angular-expanders" version="0.4.2"/>
  </expansionResources>
</expansionSettings>

Symbiotic dependencies are only included if all of their dependencies are included by other expansion-resources.

In this case, an enum-type-beam expansion-resource can add enum-type-rest-expanders and enum-type-angular-expanders as symbiotic dependencies. When used with rest-expanders, enum-type-rest-expanders will be included. When used with angular-expanders, enum-type-angular-expanders will be included.

Usage​