The root_dir override in .nvimrc.lua is not working

It tries to set root_dir on the Lua module instead of the config that will be passed to nvim-jdtls. Besides, looks like it is passing a function, and nvim-jdtls expects a string.

Let's deploy the application on Heroku to let my tutor play around with it.

Heroku seems to be the simplest platform to use and one that is free (compared to trials or limited usage from other clouds) and exposes a public IP for the service.

Investigate how difficult it would be to enable authentication so that the application is not publicly accessible (related to #35)

Deployment

Deployment should be pretty straightforward thanks to using Docker.

Resources:

• https://devcenter.heroku.com/articles/build-docker-images-heroku-yml
• https://devcenter.heroku.com/articles/container-registry-and-runtime

Database

Use https://elements.heroku.com/addons/heroku-postgresql

Application configuration

Heroku does not allow mounting additional files (application.properties) inside containers. Thus, we need to use environment variables to configure the application (mainly the database credentials).

Resources:

• https://docs.spring.io/spring-boot/docs/current/reference/html/features.html#features.external-config.typesafe-configuration-properties.relaxed-binding.environment-variables
• https://docs.spring.io/spring-boot/docs/current/reference/html/features.html#features.external-config.application-json

Required application modifications

The server must listen on the $PORT port (environment variable).

As an alternative to hardcoding the BalticLSC authentication token, it would be nice to have a way to quickly change it in the UI. Maybe we could add a button somewhere (perhaps next to the toolbox) that would show a modal that allows changing the token.

This would also help with the #34, since it requires being able to dynamically change the authentication token.

Depends on

• #18

Implement a semantic validation rule that detects when a DataFlow is between 2 pins on the same UnitCall

Depends on

• #55

Some coding rules tests report more violations when they are run with mvn test and not mvn verify.

Let's add a new CI job that runs mvn test. It should probably run in parallel to the existing job that runs mvn verify to keep the build time low.

See #62 and eclipse-sirius/sirius-web#135 (maybe the root problem of some tests not running in mvn verify is fixed upstream).

Fetch semantic validation results for a given model (use the endpoint from #14) and display them in the UI.

Do not worry about making it look pretty. Improving the UI appearance will be done in the future.

Depends on

• #14

Sometimes when running Maven without the clean target there are compilation errors:

[ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.104 s <<< FAILURE! - in org.eclipse.sirius.web.services.validation.semantic.rules.NoDataFlowLoopsTests
[ERROR] testLoop  Time elapsed: 0.06 s  <<< ERROR!
java.lang.Error:
Unresolved compilation problems:
        The method getUnits() from the type ComputationApplicationRelease refers to the missing type EList
        The method getPins() from the type UnitCall refers to the missing type EList
        The method setSource(ConnectableDataPin) in the type DataFlow is not applicable for the arguments (Object)
        The method setTarget(ConnectableDataPin) in the type DataFlow is not applicable for the arguments (Object)
        The method getFlows() from the type ComputationApplicationRelease refers to the missing type EList

        at org.eclipse.sirius.web.services.validation.semantic.rules.NoDataFlowLoopsTests.testLoop(NoDataFlowLoopsTests.java:16)

Similar errors appear in the IDE.

Let's find a way to fix them, so the types are resolved correctly and cleaning is not always required (it takes a long time). This would also unblock running tests from inside the IDE.

This may be related to the target platform file not being defined in POM. See https://github.com/ObeoNetwork/Flow-Designer/blob/master/releng/fr.obeo.dsl.designer.sample.flow.parent/pom.xml

Improve the UX by reporting status information to the user about the result of creating a unit call when clicking a toolbox entry.

This should be done by showing toast notifications using the Snackbar component, similar to how the rest of Sirius Web uses it.

Verify if the semantic validation diagnostics exposed in #14 can be streamed to the frontend via a GraphQL Subscription, similarly to how other updates are streamed to the UI.

This requires:

1. Detecting when the model is changed
2. Adding a new GraphQL Subscription type for semantic diagnostics

Get access to the contents of the model (the objects that the model contains) in the frontend programmatically.

Try to use existing ways in which the frontend application communicates with the backend (the GraphQL subscription) and console.log the contents of the currently edited model.

This is an exploratory task

Related to #12

Add a new semantic validation rule that enforces:

1. DataFlow source is a provided data pin
2. DataFlow target is a required data pin

Depends on

• #14
• #55

There are existing bounds in the metamodel that require all elements to be connected together to keep the model clean. For instance, unused ComputationUnitReleases are disallowed.

Since we decided that ComputationUnitReleases will be added to the model automatically (#18), the user will be confused when they see validation errors related to an object they did not explicitly create themselves. Relaxing these requirements should be more user-friendly and simpler than adding extra code to automatically remove those ComputationUnitReleases after the last UnitCall that calls it is removed.

Find out if the CAL metamodel in Sirius Web matches the CAL data model.

In particular, find out:

1. What are the following ApplicationDataPin properties and if they are needed?

   

   • Data Type
   • Data Structure
   • Access Type
   • Mandatory

2. Are UnitParameter and UnitParameterValue necessary? If yes, how should they be configured?

Sometimes after creating nodes programmatically (#32), there is the following exception:

Caused by: graphql.execution.NonNullableFieldWasNullException: The field at path '/diagramEvent/diagram/nodes[1]/position' was declared as a non null type, but the code involved in retrieving data has wrongly returned a null value. The graphql specification requires that the parent field be set to null, or if that is non nullable that it bubble up null to its parent and so on. The non-nullable type is 'Position' within parent type 'Node'

Caused by: graphql.execution.NonNullableFieldWasNullException: The field at path '/diagramEvent/diagram/nodes[1]/position' was declared as a non null type, but the code involved in retrieving data has wrongly returned a null value.  The graphql specification requires that the parent field be set to null, or if that is non nullable that it bubble up null to its parent and so on. The non-nullable type is 'Position' within parent type 'Node'
        at graphql.execution.ExecutionStrategy.assertNonNullFieldPrecondition(ExecutionStrategy.java:772) ~[graphql-java-17.1.jar!/:na]
        at graphql.execution.ExecutionStrategy.handleNonNullException(ExecutionStrategy.java:784) ~[graphql-java-17.1.jar!/:na]
        at graphql.execution.AbstractAsyncExecutionStrategy.lambda$handleResults$0(AbstractAsyncExecutionStrategy.java:28) ~[graphql-java-17.1.jar!/:na]
        at java.base/java.util.concurrent.CompletableFuture.uniWhenComplete(CompletableFuture.java:859) ~[na:na]
        at java.base/java.util.concurrent.CompletableFuture.uniWhenCompleteStage(CompletableFuture.java:883) ~[na:na]
        at java.base/java.util.concurrent.CompletableFuture.whenComplete(CompletableFuture.java:2251) ~[na:na]
        at graphql.execution.AsyncExecutionStrategy.lambda$execute$1(AsyncExecutionStrategy.java:74) ~[graphql-java-17.1.jar!/:na]
        at java.base/java.util.concurrent.CompletableFuture.uniWhenComplete(CompletableFuture.java:859) ~[na:na]
        at java.base/java.util.concurrent.CompletableFuture.uniWhenCompleteStage(CompletableFuture.java:883) ~[na:na]
        at java.base/java.util.concurrent.CompletableFuture.whenComplete(CompletableFuture.java:2251) ~[na:na]
        at graphql.execution.AsyncExecutionStrategy.execute(AsyncExecutionStrategy.java:66) ~[graphql-java-17.1.jar!/:na]
        at graphql.execution.ExecutionStrategy.completeValueForObject(ExecutionStrategy.java:672) ~[graphql-java-17.1.jar!/:na]
        at graphql.execution.ExecutionStrategy.completeValue(ExecutionStrategy.java:459) ~[graphql-java-17.1.jar!/:na]
        at graphql.execution.ExecutionStrategy.completeField(ExecutionStrategy.java:409) ~[graphql-java-17.1.jar!/:na]
        at graphql.execution.ExecutionStrategy.lambda$resolveFieldWithInfo$1(ExecutionStrategy.java:212) ~[graphql-java-17.1.jar!/:na]
        at java.base/java.util.concurrent.CompletableFuture.uniApplyNow(CompletableFuture.java:680) ~[na:na]
        at java.base/java.util.concurrent.CompletableFuture.uniApplyStage(CompletableFuture.java:658) ~[na:na]
        at java.base/java.util.concurrent.CompletableFuture.thenApply(CompletableFuture.java:2094) ~[na:na]
        at graphql.execution.ExecutionStrategy.resolveFieldWithInfo(ExecutionStrategy.java:211) ~[graphql-java-17.1.jar!/:na]
        at graphql.execution.AsyncExecutionStrategy.execute(AsyncExecutionStrategy.java:60) ~[graphql-java-17.1.jar!/:na]
        ... 67 common frames omitted
Caused by: graphql.execution.NonNullableFieldWasNullException: The field at path '/diagramEvent/diagram/nodes[1]/position/x' was declared as a non null type, but the code involved in retrieving data has wrongly returned a null value.  The graphql specification requires that the parent field be set to null, or if that is non nullable that it bubble up null to its parent and so on. The non-nullable type is 'Float' within parent type 'Position'
        at graphql.execution.NonNullableFieldValidator.validate(NonNullableFieldValidator.java:49) ~[graphql-java-17.1.jar!/:na]
        at graphql.execution.ExecutionStrategy.completeValueForScalar(ExecutionStrategy.java:606) ~[graphql-java-17.1.jar!/:na]
        at graphql.execution.ExecutionStrategy.completeValue(ExecutionStrategy.java:446) ~[graphql-java-17.1.jar!/:na]
        at graphql.execution.ExecutionStrategy.completeField(ExecutionStrategy.java:409) ~[graphql-java-17.1.jar!/:na]
        at graphql.execution.ExecutionStrategy.lambda$resolveFieldWithInfo$1(ExecutionStrategy.java:212) ~[graphql-java-17.1.jar!/:na]
        at java.base/java.util.concurrent.CompletableFuture.uniApplyNow(CompletableFuture.java:680) ~[na:na]
        at java.base/java.util.concurrent.CompletableFuture.uniApplyStage(CompletableFuture.java:658) ~[na:na]
        at java.base/java.util.concurrent.CompletableFuture.thenApply(CompletableFuture.java:2094) ~[na:na]
        at graphql.execution.ExecutionStrategy.resolveFieldWithInfo(ExecutionStrategy.java:211) ~[graphql-java-17.1.jar!/:na]
        at graphql.execution.AsyncExecutionStrategy.execute(AsyncExecutionStrategy.java:60) ~[graphql-java-17.1.jar!/:na]
        ... 76 common frames omitted

Encountering it means that the model is no longer usable. To be able to use it again, all the objects must be removed from the model (using the explorer tree) and the website has to be refreshed. Only then will the diagram work.

This is frustrating and could lead to data loss (having to remove the objects in the model). Let's find out why that happens and try to fix it.

Related to

• #32
• eclipse-sirius/sirius-web#828

Start a PostgreSQL instance in CI, then the application server, and run end-to-end tests in GitHub Actions.

See documentation on starting PostgreSQL in GitHub Action workflows.

There are no e2e tests at the moment, though, so they should probably be created first.

Let's create a proposal for how to integrate CAL-web into BalticLSC.

Roughly:

1. On the Development Shelf page, there will be a new button next to Edit Diagram. Clicking this button will

   1. Ask the BalticLSC backend for the model structure of that diagram.

      The model structure should include:

      • DeclaredDataPins of the diagram
      • UnitCalls
      • used ComputationUnitReleases (could be the same shape as in the toolbox)
      • DataFlows between DataPins
      • (probably) extra parameters (#37)

   2. Send it to the CAL-web backend.

   3. CAL-web backend will:

      1. Create a new project for that user
      2. Add the model structure into that project

2. At this point, the BalticLSC frontend can show the Sirius Web frontend.

   Sirius Web frontend will allow editing only that project. There will be no buttons to go to "Projects" page.

   The BalticLSC frontend must pass the authentiation token to the Sirius Web frontend, so it can fetch the contents of the user's toolbox.

   Sirius Web frontend must be notified when the authentication token is refreshed.

3. The user modifies the diagram.

   They have access to their toolbox, similarly to the existing BalticLSC diagram editor.

   They get validation messages using Sirius Web validations (see the model validation project for more information).

4. Once the user is done with editing the diagram, they can click "Save".

   This instructs one of the frontends (either BalticLSC or Sirius Web - to be decided) to send the serialized model structure to the BalticLSC frontend. It will persist the model in the BalticLSC database.

5. When the user leaves the Sirius Web frontend, it sends a request to Sirius Web backend to remove the project.

   This way the database is not pollutted with leftover models.

   Opening the same model again will start the process from point 1. There is no caching of models to avoid having to synchronize both backends.

It would be great to draw it as a sequence diagram.

The integration itself will most likely be out of scope of the thesis.

Includes

• #34
• #92

strict is currently disabled in tsconfig.json

Let's enable it to ensure greater code quality, safety, and more compile-time checks.

This requires fixing around 40 TS errors.

There are definitions for existing packages that are not used in the application and could be removed to make the application more lightweight and avoid extra choices in the UI.

Those include:

• flow metamodel packages in pom.xml
• extra domains and stereotypes

Sirius Web assumes the icons are always 16px (eclipse-sirius/sirius-web#782).

Let's resize the icons to 16px so they look nicer in the UI.

Check how to add model objects programmatically from the frontend. Adding any object to the diagram is good enough to call this ticket done because changing the object that was added should be straightforward.

The end goal is being able to add a ComputationUnitRelease from the toolbox (fetched from #11) into the model and ultimately show it in the diagram.

This is an exploratory issue.

Similarly to the behavior of the diagram editor in the main BalticLSC application, clicking on a ComputationUnitRelease in the toolbox should add a UnitCall in the model.

Concretely, it should:

1. Add a ComputationUnitRelease to the model. If one already exists, this should be skipped.

2. Add a UnitCall and point its unit to the ComputationUnitRelease from point 1.

   This should automatically create DataPins on the UnitCall based on the ones from the ComputationUnitRelease.

This task is only for the frontend part. The backend part is addressed in #32.

Open questions

None. Answered in comments below.

Tasklist

• Recreate workbench UI using exposed Sirius Components
  • Explorer
  • Validation
  • Details
  • Diagram editor
• Clean up unnecessary props from the recreated workbench UI
• Inject a new component that lists toolbox entries
• Send a createUnitCall mutation when the user clicks a toolbox entry

Depends on

• #11
• #12
• #13
• #32

In the original BalticLSC diagram editor, required ApplicationDataPins have a black bar on their right

In our metamodel, the black bar is always on the left. Let's add new icons and add conditional styles to match the original diagram editor.

Depends on

• eclipse-sirius/sirius-web#865

Based on the investigation from #33, implement a model validation provider (a class that implements IValidationDescriptionProvider) for additional semantic CAL model validations.

Idea

There will be a new interface

interface ISemanticCALValidationRule {
  List<Diagnostic> validate(ComputationApplicationRelease application);
}

Each semantic rule (e.g. #27) will implement it.

The SemanticCALValidationDescriptionProvider will receive a list of ISemanticCALValidationRules and propagate the concatenated diagnostics returned by running each rule.

Resources

• the EMFValidationService used in Sirius Components to show the EMF model validation

  https://github.com/eclipse-sirius/sirius-components/blob/master/backend/sirius-web-emf/src/main/java/org/eclipse/sirius/web/emf/services/EMFValidationService.java

• how to get the objects inside of an EditingContext

  https://github.com/eclipse-sirius/sirius-components/blob/ab8097c6c3593f10fdd16f9212762624a3639ccc/backend/sirius-web-emf/src/main/java/org/eclipse/sirius/web/emf/services/EMFValidationService.java#L110-L112

  Note that this uses the EditingContext class, not the IEditingContext interface.

  That class just casts IEditingContext to EditingContext: https://github.com/eclipse-sirius/sirius-components/blob/ab8097c6c3593f10fdd16f9212762624a3639ccc/backend/sirius-web-emf/src/main/java/org/eclipse/sirius/web/emf/services/EMFValidationService.java#L54-L62

  We can probably do the same.

It turns out that ComputationUnitRelease is an abstract class with 2 possible concrete instances:

1. ComputationModuleRelease - a computation module (the lowest level abstraction)
2. ComputationApplicationRelease - another application model that can be used as a part of the current model

This means that diagrams (ComputationApplicationReleases) can be nested inside one another. It is not something that we need to model on the diagram, but worth keeping in mind.

See the CAL metamodel.

Thus, we need to create:

1. Create 2 new classes
2. Make ComputationUnitRelease abstract
3. Inspect the code that interacts with ComputationUnitReleases to see if it needs to be adjusted (probably not, because declaredPins are the same in both cases).

Add a GitHub workflows that introduces basic git hygiene checks:

1. https://github.com/marketplace/actions/block-fixup-commit-merge
2. https://github.com/wagoid/commitlint-github-action

along with a conventional commit config file.

Also, add a pre commit hook: https://github.com/alessandrojcm/commitlint-pre-commit-hook

I have a hunch that there is no type-checking of the frontend project in CI. Let's verify it and add the necessary commands / npm scripts.

The copy-frontend.sh script assumes the $script_dir is the root of the repository:

17:16 $ ../scripts/copy-frontend.sh
cp: cannot stat '/home/voreny/projects/studia/magisterka/CAL-web/scripts/frontend/build/*': No such file or directory

The .settings directory is ignored in .gitignore. This makes it so that Eclipse language server uses its default formatting settings. The resulting formatting after saving a Java file is often different from the original formatting from the https://github.com/eclipse-sirius/sirius-web repository.

Thus, let's include the .settings/org.eclipse.jdt.core.prefs files for each sirius-web-* project in backend.

Outline of the project roadmap.

Roadmap

Thesis scope

Filter

• EMF metamodel for CAL (based on the original data model) working in Sirus Desktop
• CAL model working in Sirius Web (manual manipulation of the model, no extra features)
• Basic model automation
  • Synchronizing ComputedDataPins for a UnitCall based on the ComputationUnitRelease it calls
  • Removing DataFlows when one of its ends is removed
• Support BalticLSC toolbox (#18, https://github.com/Gelio/CAL-web/projects/3)
• Semantic metamodel validation (filter, not required)
• Align CAL metamodel definitions (filter, not required)
• RFC for integrating CAL-web in BalticLSC (#41)
• Write the thesis paper (project, filter, not required)

Out of thesis scope

• BalticLSC data model integration
  • Create a Sirius Web model based on BalticLSC model
  • Per-user model visibility (#35)
  • Export a Sirius Web model to a BalticLSC model
• BalticLSC frontend integration

DataFlow and ComputedDataPin do not have any labels in the model and look very generic in the explorer tree.

This could be fixed by adding a label to them:

• for DataFlow, it could say which 2 ConnectableDataPins it connects
• for ComputedDataPin, it could repeat the name of its declared data pin

Solutions to try:

• Change getText for some ItemProviders in the .edit model project
• Add a derived attribute to them and try to assign it a name (see https://inf.mit.bme.hu/sites/default/files/publications/ecmfa2012_derived_features.pdf)

Download the list of toolbox entries for the currently logged in user in BalticLSC and show them in the console.

Do not worry about authentication for now. Hardcode the JWT in the source code.

If there are CORS problems, add a backend endpoint that will proxy to BalticLSC. Make sure the URL that the UI uses to connect to BalticLSC is configurable so that it can use the proxy, the real URL, or some local BalticLSC backend URL, if need be.

Let's create an RFC describing my proposal on how to embed CAL-web into the BalticLSC frontend, as an alternative diagram editor.

Include the following subjects:

1. Exposed CAL-web API (how to render CAL-web inside of a vue application, how to unmount it)
2. Passing the authentication token to CAL-web

This is a prerequisite of the meeting with the BalticLSC frontend team to discuss the integration. Having a written proposal should make the meeting more productive.

Integration of backends will be described in #41.

Depends on

• #92

Add icons for model objects that are displayed in the explorer tree.

At the moment, the default icons are displayed for each element

Depends on

• eclipse-sirius/sirius-web#866

A ComputationModuleRelease can have many CredentialParameters, as shown in the CAL metamodel.

This needs to be added to the metamodel in this repository.

Needs research on what those are and what they are used for.

Depends on

• #16

Before implementing custom endpoints for model validations (#14), let's investigate how built-in model validation works.

https://github.com/Gelio/CAL-web/blob/main/backend/sirius-web-services/src/main/java/org/eclipse/sirius/web/services/validation/ValidationDescriptionProvider.java

Maybe we could leverage the built-in validation instead of building our own.

Add a new model semantic validation rule that checks if each ConnectableDataPIn has at most 1 data flow. It should report errors when a ConnectableDataPin has an outgoing and an incoming DataFlow.

The NoDataFlowLoops semantic validation rule was added to the codebase without tests. Let's add them, so it's easier to verify that it is working correctly and we improve the quality of the project.

https://github.com/Gelio/CAL-web/blob/main/backend/sirius-web-services/src/main/java/org/eclipse/sirius/web/services/validation/semantic/rules/NoDataFlowLoops.java

It is possible that dead-ends should be forbidden.

A dead-end is when a UnitCall gets a token on its required DataPins, but its provided DataPins are not connected.

Needs research if it is a valid rule.

Depends on

• #14
• #55

At the moment, the toolbox is fetched only at the application start. If the user modifies the toolbox in the meantime by adding/removing unit releases, they need to reload the page to see the changes.

It would be a better user experience if there was a button to refresh the toolbox without refreshing the application.

There is no benefit from showing ComputationUnitReleases on the diagram.

Let's hide them from the diagram (delete the appropriate mapping in the odesign file)

Following the investigation done in #12 (comment), let's create a Spring controller that would get a BalticLSC Toolbox entry (already fetched in #11) and an editingContextId. It would find the model, create a new UnitCall to it and optionally create a new ComputationUnitRelease too.

If possible, try to make it a new GraphQL mutation that hooks into existing Sirius Web mutations, instead of a Spring controller. This way the whole application could stay within GraphQL to communicate within Sirius.

Example Toolbox entries

{
  "image": "",
  "command": "",
  "commandArguments": [],
  "variableMappings": [],
  "requiredServices": [],
  "unit": {
    "name": "Bounding Labels",
    "uid": "4c4b9120-9cc6-414a-b5e7-4254d451d76b",
    "pClass": null,
    "shortDescription": null,
    "longDescription": null,
    "keywords": null,
    "icon": "https://www.balticlsc.eu/model/_icons/default.png",
    "isApp": false,
    "isService": false
  },
  "version": "0.11",
  "uid": "110f65c2-3fc6-411c-9ded-8c8cf96db52d",
  "status": 0,
  "date": "2021-09-30T19:01:28.379053",
  "description": "Bounding Labels0.11",
  "openSource": false,
  "usageCounter": 0,
  "pins": [
    {
      "uid": "c915d7a5-dec5-4b60-9fdb-00eed6591cc4",
      "name": "Input",
      "binding": 0,
      "tokenMultiplicity": 0,
      "dataMultiplicity": 0,
      "dataTypeUid": "dd-003-002",
      "dataTypeName": "PNG",
      "dataStructureUid": null,
      "dataStructureName": null,
      "accessTypeUid": "dd-004-001",
      "accessTypeName": "MongoDB"
    },
    {
      "uid": "76c05ac4-4b34-4053-97e5-8d65748d1485",
      "name": "Output",
      "binding": 2,
      "tokenMultiplicity": 0,
      "dataMultiplicity": 0,
      "dataTypeUid": "dd-003-002",
      "dataTypeName": "PNG",
      "dataStructureUid": null,
      "dataStructureName": null,
      "accessTypeUid": "dd-004-001",
      "accessTypeName": "MongoDB"
    }
  ],
  "supportedResourcesRange": {
    "minCPUs": -1,
    "minGPUs": -1,
    "minMemory": -1,
    "minStorage": -1,
    "maxCPUs": -1,
    "maxGPUs": -1,
    "maxMemory": -1,
    "maxStorage": -1
  }
}

{
  "diagramUid": "bd37887e-3c8d-49d4-9988-fd06a1f8eaa8",
  "unit": {
    "name": "Distance Matrix Calculator",
    "uid": "6d0be02e-4860-45cd-8cde-0d766feefa48",
    "pClass": null,
    "shortDescription": "Finds all distances between given addresses using user-provided map",
    "longDescription": null,
    "keywords": null,
    "icon": "https://www.balticlsc.eu/model/_icons/default.png",
    "isApp": true,
    "isService": false
  },
  "version": "v0.1",
  "uid": "12f8248a-fc17-48f6-8305-f5f85cfdfaf6",
  "status": 0,
  "date": "2021-10-22T10:47:45.686311",
  "description": null,
  "openSource": false,
  "usageCounter": 0,
  "pins": [
    {
      "uid": "c28002b5-af5f-4665-83b7-319151219171",
      "name": "Geo Objects",
      "binding": 0,
      "tokenMultiplicity": 0,
      "dataMultiplicity": 0,
      "dataTypeUid": "dd-001-001",
      "dataTypeName": "JSON",
      "dataStructureUid": null,
      "dataStructureName": null,
      "accessTypeUid": "dd-006-000",
      "accessTypeName": "FTP"
    },
    {
      "uid": "57dc55d7-dc7e-4a24-9a9f-ea9b99ac35e7",
      "name": "Map",
      "binding": 0,
      "tokenMultiplicity": 0,
      "dataMultiplicity": 0,
      "dataTypeUid": "dd-001-000",
      "dataTypeName": "DataFile",
      "dataStructureUid": null,
      "dataStructureName": null,
      "accessTypeUid": "dd-006-000",
      "accessTypeName": "FTP"
    },
    {
      "uid": "6c38bfcb-a498-4a7e-b745-000655ed2680",
      "name": "Matrix",
      "binding": 2,
      "tokenMultiplicity": 0,
      "dataMultiplicity": 0,
      "dataTypeUid": "dd-001-001",
      "dataTypeName": "JSON",
      "dataStructureUid": null,
      "dataStructureName": null,
      "accessTypeUid": "dd-006-000",
      "accessTypeName": "FTP"
    }
  ],
  "supportedResourcesRange": {
    "minCPUs": 0,
    "minGPUs": 0,
    "minMemory": 0,
    "minStorage": 0,
    "maxCPUs": 0,
    "maxGPUs": 0,
    "maxMemory": 0,
    "maxStorage": 0
  }
}

Tasklist

• Add a DTO for ComputationUnitRelease
• Add a new mutation that retrieves it along with the editing context ID
  • Add the ComputationUnitRelease to the model
  • Detect if the ComputationUnitRelease is already in the model. If yes, skip adding it
  • Add a UnitCall to the model

Depends on

• #16 (not sure, to be investigated)

There are errors when running

$ ./mwnv clean test
[ERROR] Tests run: 6, Failures: 2, Errors: 1, Skipped: 0, Time elapsed: 0.061 s <<< FAILURE! - in org.eclipse.sirius.web.services.architecture.ImmutableTests
[ERROR] immutableClassesShouldHaveAPrivateConstructor  Time elapsed: 0.022 s  <<< FAILURE!
java.lang.AssertionError:
Architecture Violation [Priority: MEDIUM] - Rule 'classes that reside in a package 'org.eclipse.sirius.web.services..' and are annotated with @Immutable and are not annotated with @GraphQLInputObjectType should have only private constructors' was violated (2 times):
Constructor <org.eclipse.sirius.web.services.api.projects.UnzippedProject.<init>()> is not private in (UnzippedProject.java:31)
Constructor <org.eclipse.sirius.web.services.api.representations.RepresentationDescriptor.<init>()> is not private in (RepresentationDescriptor.java:27)

[ERROR] immutableClassesShouldBeFinal  Time elapsed: 0.005 s  <<< FAILURE!
java.lang.AssertionError:
Architecture Violation [Priority: MEDIUM] - Rule 'classes that reside in a package 'org.eclipse.sirius.web.services..' and are annotated with @Immutable should have modifier FINAL' was violated (2 times):
Class <org.eclipse.sirius.web.services.api.projects.UnzippedProject> does not have modifier FINAL in (UnzippedProject.java:0)
Class <org.eclipse.sirius.web.services.api.representations.RepresentationDescriptor> does not have modifier FINAL in (RepresentationDescriptor.java:0)

[ERROR] immutableClassesShouldHaveANestedBuilder  Time elapsed: 0.007 s  <<< ERROR!
java.lang.IllegalArgumentException: No field with name 'projectManifest in class org.eclipse.sirius.web.services.api.projects.UnzippedProject$Builder

They seem to appear in the code from the Sirius Web repository.

Add an endpoint in the backend application that returns a list of diagnostics after running semantic validations on a model.

Use a very basic semantic validation rule, for example:

A DataFlow must be between DataPins on 2 different UnitCalls

Before adding a new endpoint, let's complete the investigation in #33

Depends on

• #33

Backend and frontend can be built in parallel in GitHub Actions. After they are built, frontend assets could be copied into the built JAR by:

1. Building only the sirius-web-frontend JAR
2. Copying it into the sirius-web-sample-application JAR directly by using https://stackoverflow.com/a/14388993/4874344

This should speed up the CI by about 2x, since the two jobs that run sequentially ATM each take around 2 minutes. If they run in parallel, they will take 2 mins each, and then there will be another short job to integrate the results.

When CAL-web is going to be embedded in the main BalticLSC frontend (#34), users should not have access to other people's diagrams.

This means that most likely each user should have their own Sirius Web project and their diagrams should appear in that model.

This requires some investigation regarding the authentication features that Sirius Web provides.

After a DataFlow is automatically removed (for example when removing an ApplicationDataPin and the attached DataFlows are also removed), there is a warning about a DanglingHFREException.

Let's investigate how to fix it.

One idea is to manually clear the back-references to DataFlow when is it removed.

The exception only happens in Sirius Web. In Sirius Desktop, everything works smoothly. Upstream bug for Sirius Web: eclipse-sirius/sirius-web#792

Add a Dockerfile for the backend application. It would contain the recipe for building the application in an easily reproducible way.

We could go further and add a docker-compose for running the backend, frontend, and the database with just a single command.

The black bar in the ApplicationDataPin icons in the original BalticLSC diagram editor is wider than in our editor

Let's make it a bit wider to match the appearance of the original editor.

Add a new semantic validation rule that enforces there are no cycles between DataFlow (similar to cycles in a graph).

Connection graph

A ComputationApplicationRelease is a directed graph for which:

• nodes are ApplicationDataPins and UnitCalls
• there is an edge between an ApplicationDataPin and UnitCall if there is a DataFlow between the source node (a provided ApplicationDataPin itself or any provided ComputedDataPin for UnitCalls) and the target node (a required ApplicationDataPin itself or any required ComputedDataPin for UnitCalls)

Detecting cycles

Cycles could be detected by running a DFS on the graph of connections.

To make the implementation simpler, let's only detect and report the first encountered cycle. Reporting all cycles is out of scope of this task.

Diagnostics

If there is a cycle, let's report all node names on that cycle in an error diagnostic.

If there is no cycle, let's add an info diagnostic that the graph is valid (tentative, could be misleading. If so, drop this requirement).

Depends on

• #14
• #55

The order of elements in lists in the metamodel does not matter. Thus, let's make them unordered, so the metamodel is more precise.