It just looks like a black and white mess:

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Rate-Limited

These updates are currently rate-limited. Click on a checkbox below to force their creation now.

• Update dependency karma to v6.4.3
• Update dependency org.apache.maven.plugins:maven-deploy-plugin to v3.1.2
• Update dependency org.apache.maven.plugins:maven-install-plugin to v3.1.2
• Update dependency webpack-bundle-analyzer to v4.10.2
• Update dependency org.apache.maven.plugins:maven-compiler-plugin to v3.13.0
• Update dependency org.apache.maven.plugins:maven-jar-plugin to v3.4.1
• Update xtext.version to v2.34.0 (org.eclipse.xtext:org.eclipse.xtext, org.eclipse.xtext:xtext-dev-bom)
• 🔐 Create all rate-limited PRs at once 🔐

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• Update dependency jasmine-core to v5.1.2
• Update dependency org.apache.maven.plugins:maven-shade-plugin to v3.5.3
• Update Font Awesome (@fortawesome/angular-fontawesome, @fortawesome/fontawesome-svg-core, @fortawesome/free-brands-svg-icons, @fortawesome/free-regular-svg-icons, @fortawesome/free-solid-svg-icons)
• Update dependency com.regnosys.rosetta:com.regnosys.rosetta to v9.8.0
• Update logback.version to v1.5.6 (ch.qos.logback:logback-core, ch.qos.logback:logback-classic)
• Update actions/setup-java action to v4
• Update actions/upload-artifact action to v4
• Update dependency com.google.guava:guava to v33
• Update dependency date-fns to v3
• Update dependency org.finos.cdm:cdm-java to v6
• Click on this checkbox to rebase all open PRs at once

Ignored or Blocked

These are blocked by an existing closed PR and will not be recreated unless you click a checkbox below.

• Update dependency typescript to ~4.9.0
• Update dependency zone.js to ~0.14.0
• Update angular monorepo to v17 (major) (@angular/animations, @angular/common, @angular/compiler, @angular/compiler-cli, @angular/core, @angular/forms, @angular/platform-browser, @angular/platform-browser-dynamic, @angular/router)
• Update angular-cli monorepo to v17 (major) (@angular-devkit/build-angular, @angular/cli)
• Update angularmaterial monorepo to v17 (major) (@angular/cdk, @angular/material, @angular/material-date-fns-adapter)
• Update dependency com.regnosys.rosetta:com.regnosys.rosetta to v10
• Update dependency typescript to v5

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository

Object Builder to become more generic in loading data model

Description of Problem:

The CDM Object Builder is currently closely tied to the loading and navigating of the Common Data Model. If made more generic, this object builder would allow for a developer forking the repository to run a build with a different data model, perhaps an extension of the CDM or one of similar structure available within the Rosetta file path structure.

Potential Solutions:

The build currently relies on parameter arguments passed into the main java class that generates the Object Builder to load the related data model as specified in dependencies. However, it has some custom code that could be made more generic to allow for the build to accommodate a different data model to be loaded.

Impacted Java class: TypescriptObjectBuilderModelGenerator
Method: loadModels is currently using the ClassPathUtils method findRosettaFilePaths which is currently tied to the Common Domain Model structure.

AS-IS

    private List<RosettaModel> loadModels() throws MalformedURLException {
        XtextResourceSet resourceSet = resourceSetProvider.get();
        List<Path> rosettaFilePaths = ClassPathUtils.findRosettaFilePaths();
        for (Path rosettaFilePath : rosettaFilePaths) {
            resourceSet.getResource(URI.createURI(rosettaFilePath.toUri().toURL()
                    .toString(), true), true);
        }

        return resourceSet.getResources().stream()
                .map(Resource::getContents)
                .flatMap(Collection::stream)
                .map(RosettaModel.class::cast)
                .collect(Collectors.toList());
    }

The model is currently hardcoded in the ClassPathUtils class findRosettaFilePaths method:

    public static List<Path> findRosettaFilePaths() {
        return findPathsFromClassPath(ImmutableList.of("model", "cdm/rosetta"), ".*\\.rosetta", Optional.empty(), ClassPathUtils.class.getClassLoader());
    }

If passing a parameter in the method with the chosen data model name (from those available in the path structure), this could be controlled during build to switch to a different model.

TO-BE
In loadModels method:
findRosettaFilePaths(modelName);

In findRosettaFilePaths - it would take the modelName as a String parameter, something like this:

 public static List<Path> findRosettaFilePaths(String modelName) {
        return ClassPathUtils.findPathsFromClassPath(ImmutableList.of("model", modelName + "/rosetta"), ".*\\.rosetta", Optional.empty(), ClassPathUtils.class.getClassLoader());
    }

Exception Handling
A modelName that cannot be found on the file paths would need to be handled.

CVE scanning failure at - https://github.com/eacunaISDA/object-builder/actions/runs/6039273502/job/16387539600#step:5:6023

CVE details can be found at https://nvd.nist.gov/vuln/detail/CVE-2023-2976. It says "Even though the security vulnerability is fixed in version 32.0.0, we recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Window".

Given the above we suggest trying to use 32.0.1 version for guava.

To update the version we can check where it comes from (it seems to be a transitive dependency). (Run mvn dependency:tree to see where it comes from). Possible solutions:

1. Could be that a new version of the root dependency (the one you can update in pom.xml) has a new version, which also uses 32.0.1 (or newer version) of guava.
2. If 1 doesn't work, you can "exclude" guava, (see https://www.educba.com/maven-exclude-dependency/) , then add it as a root dependency with the version of your choice
3. We can decide to ignore it (if safe to do so) by adding the CVE to an allow-list.xml file

After we address this we can make the repository public.

At the moment, the favicon used on CDM Object Builder is the Angular one, see https://main--super-kitsune-8d7875.netlify.app/favicon.ico

Would be great to use a .ico version of https://landscape.finos.org/logos/common-domain-model.svg (just the logo part)

Bug Report

Steps to Reproduce:

1. Open the Object Builder
2. Select EligibleCollateralSpecification as the root type
3. Add a criteria and an asset
4. Select denominatedCurrency
5. Attempt to select EUR or GBP from the dropdown.

Expected Result:

Major currencies, that is members of the CurrencyCodeEnum and ISOCurrencyCodeEnum enumerated lists, should appear as available to be selected.

Actual Result:

Only the values from the CurrencyCodeEnum list appear. CurrencyCodeEnum inherits from ISOCurrencyCodeEnum however the values from the latter enumerator list are not shown.

Environment:

CDM-JAVA5.0.1

Additional Context:

Similar behaviour may be demonstrated in other instances where inheritance is used with enumerated lists; weeklyRollConvention on an interestRatePayout being another example.

Bug Report

Steps to Reproduce:

1. Create an Eligibile Collateral Specification
2. Add an Identifier
3. Add the first Party, with a name
4. Add the second Party, with a name

Expected Result:

In either table or JSON view, would expect to see both parties

Actual Result:

Only the last Party is shown

Environment:

(https://cdm-object-builder.finos.org/)
CDM-JAVA5.0.1

Additional Context:

{
"identifier": [
{
"assignedIdentifier": [
{
"identifier": {
"value": "A12345678"
}
}
]
},
{
"assignedIdentifier": [
{
"identifier": {
"value": "sdsadasd"
}
}
]
}
],
"party": {
"name": {
"value": "BNPP"
}
}
}

Feature Request

Description of Problem:

When selecting an attribute with multiple cardinality, Object Builder does not enforce the maximum bound (or indeed the minimum bound either). That is (0..1) is treated the same as (0..2) and (0..*) etc.

This means that it is possible to create non-compliant objects unintentionally which will not work in the CDM.

Potential Solutions:

Validate number of occurences and raise a warning message if it exceeds the CDM specification. Probably better that this is not a breaking error as there may be occasions where an end user wants to create invalid data knowingly.