CLI - Configuration of a V-SUMM

[NeumannDirk]

The configuration of the V-SUMM should follow the steps of the methodologist template and add some handy CLI functionality.

• Starting the Vitruv-Shell

  • proposed command: vitruv

• Adding Metamodels to the Configuration

  • proposed command: add-metamodel or short add-mm <path to .ecore-file> -flags(?)
    • should be an arbitrary string (or lets say just [a-z,A-Z,0-9]{3-*} or so) to identify the metamodel instead of using something like the namespace uri (which nobody will know by heart)
    • -c to copy metamodel (standard)
    • -m to move metamodel
    • maybe just go with copying
  • at least two metamodels should be added
  • proposed command: remove-metamodel or short rem-mm -d
    • removes metamodel from V-SUMM config
    • from add-command
    • '-d' if set, also deletes metamodel from disk

• Adding Reactions to the Configuration

  • proposed commands add-reaction/ add-rc <path to .reaction-file> -flags(?)
    • see add-metamodel
    • additional validation step to check if sourc and target metamodel are already known in the configuration
  • proposed commands remove-reaction/ rem-rc -d
    • see remove-metamodel
  • proposed commands check-reaction-coverage/ chk-rc-cov to list and check between which metamodels and in which directions do reactions exist
    • identify “dangling metamodels” which are not connected to the rest
    • maybe in future this can go down to the “trigger-level” to identify “un-addressed original changes”
  • proposed command enable-transitive-changes/ en-tc and disable-transitive-changes/ dis-tc
    • I do not know if this is even possible at the moment but just for completion

• (Adding view descriptions)

  • I guess this point needs some more work beforehand. For me this creates a few new questions like:
    • Can we already address Single/Multi-Model Views
    • Are the same reactions used and what happens if the repair of one part of an original change overwrites the second part of the original change.

• Additional Commands

  • proposed command save-configuration/ safe-cfg
    • as above to easily switch between V-SUMMs
    • saves the configuration in some format that is easily readable/ understandable
    • I do not know if there is some zipping, moving, unzipping of folders needed or if this is a use case that can maybe be “lifted” to the V-SUMM-level (build the V-SUMM and save its “.exe” or so)
  • proposed command load-configuration/ load-cfg
    • loads a configuration and lets you continue or adjust its parts
  • proposed command exit-configuration/ exit
    • just close the shell application (Do you want to save? Progress will be lost! or so)
  • proposed command build-vsumm/ build/ start
    • freezes configuration and starts maven. V-SUMM is built and the next consol application starts (other sub-issue)
  • proposed command show-configuration/ show-cfg/ show
    • prints the whole configuration into the console
  • proposed command check-configuration/ chk-cfg/ check
    • prints the whole configuration into the console AND also checks the reactions (see above) and in the future the views
  • note that short commands like show and check may become ambiguous when there is also a CLI for interacting with the V-SUM(M)
  • proposed command help
    • lists all the commands with explanation and parameters.

I think there are multiple 3rd party frameworks for these ideas. This list should be considered a first draft and subject to discussions. Please reach out to me if you have remarks/ ideas.
Dirk

[TomWerm]

Thank you very much for rising this enhancement request.

I have some first trials with apache-cli on the vitruv-cli branch, e.g., https://github.com/vitruv-tools/Vitruv/blob/vitruv-cli/cli/src/main/java/tools/vitruv/framework/cli/CLI.java.

I think it would be beneficial to distinguish between commands and parameters for those commands.

Also, we have to keep in mind, that there is no configuration management available (See vitruv-tools/Vitruv#444) as of yet.

https://github.com/vitruv-tools/Vitruv/blob/vitruv-cli/cli/src/main/java/tools/vitruv/framework/cli/options/MetamodelOption.java allows adding metamodels with ecore and genmodel files. In general, I think we can go for copying at a folder location of the users choice (https://github.com/vitruv-tools/Vitruv/blob/vitruv-cli/cli/src/main/java/tools/vitruv/framework/cli/options/FolderOption.java), instead of adding that additional layer with referencing it (also makes path handling easier, as we have to bring everything in a specific structure so we can apply the maven build (and also we might have to add things to classpaths, modify absolute paths, etc.)).

For a first iteration I would restrict the CLI to only “build” V-SUMs, rather than completely configuring them (including removing parts, which might prove difficult, due to links in other models, e.g., the correspondence model).

We also need a way to include a custom user interactor (https://github.com/vitruv-tools/Vitruv/blob/vitruv-cli/cli/src/main/java/tools/vitruv/framework/cli/options/UserInteractorOption.java).

check-reaction-coverage Hmm, currently nothing in that line is implemented, is that supposed to work on the headers of the reactions files or also on their content. Especially in the second case, this will be quite some work and static analysis to implement, which I would rather move to a dedicated (new) analysis module and after that has been added, also add it to the CLI as well.

help should be done with the means of the library used, i.e., it should be generated automatically.