Should we keep the possibility to have the "behavior" layer for ecore ?

[dvojtise]

The feature allowing to add a "behavior" layer on top of an ecore when both the ecore and ale files are in the same project is currently broken (cf.#147)

should we fix it ? or completely re-specify this feature ? or remove it ?

In the current version it tends to push the idea of having the ale and ecore in the same project, while in most other project we try to push the idea of decoupling them (static part on one side, dynamic one in another, with possibility to write several behavior variants for different usages)

How can we refactor this in order to emphasize this separation ?

[echebbi]

The feature allowing to add a "behavior" layer on top of an ecore when both the ecore and ale files are in the same project is currently broken (cf.#147)

I can confirm that this feature works. The Behavior layer is based on the project's ALE environment and thus works whether the .ecore/.ale files are within the project or not (see #134).

Don't forget to select the layer:

1. Right-click on the .aird > Viewpoints Selection > Check Behavior
2. From the editor click on the Layers icon > Check Behavior
3. Right-click on the blank area > Refresh (the representation is not automatically updated anymore because of Decouple ALE environment from .dsl file #115)

Note that this is documented in the new website (temporary URL: https://blog.echebbi.fr/ale-lang-docs/features/sirius-integration/) and that we still have to make it official!

In the current version it tends to push the idea of having the ale and ecore in the same project

I disagree: the wizard allows to create a new ALE project that relies on an Ecore from another project. Since the Behavior works as well there's no reason to put ALE source files next to the Ecore metamodel.

How can we refactor this in order to emphasize this separation?

We have to update our tutorials/examples to outline that.

should we fix it ? or completely re-specify this feature ? or remove it ?

As per our discussion I think we agree that keeping this layer is important. It also seems to actually work "as expected" (we still have lots of improvements to make, but it works) and allows for a separation between static and dynamic parts.

As a result it's more a matter of making the layer stable and improving existing features than re-specifying/removing the layer. I close this issue for now: more specific issues will be created to address possible bugs/flaws. Feel free to reopen if I'm mistaken.