search

archimatetool / archi-modelrepository-plugin

coArchi - a plug-in to share and collaborate on Archi models.
153 stars 53 forks source link

Use extension points to expose Grafico export/import #12

Open jbsarrodie opened 7 years ago

jbsarrodie commented 7 years ago

[This is not part of a sprint but logged for the future]

Now that this plugin exists, we could deprecate the grafico plugin and use extension points to add menu entries to import/export from Grafico (as this can be needed for power users). This would also avoid maintaining two codebases.

pijalu commented 5 years ago

It would be nice to also have a reload option when doing manual git operation to resync archi with the grafico content...

Or even better: Allow a 'native' support of grafico within archi ?

cima commented 5 years ago

We use Grafico plugin with a native git because our GIT repository has deeper structure (grafico files are not in the root). Having 'native support of Grafico' that would act as a regular *.archimate file (e.g. CTRL+S to save) would be best solution for US. We are familiar with git enough to have external tool for versioning. (Plus we have no other than SSH access to git.) The pain now is that we have to start archi, click import... do stuff... click export and confirm overwrite.

jbsarrodie commented 5 years ago

It would be nice to also have a reload option when doing manual git operation to resync archi with the grafico content...

Not possible because a model loaded from Grafico is always seen as a new model, so there's no way to keep the "link" with the original folder from which model was loaded.

Or even better: Allow a 'native' support of grafico within archi ? Having 'native support of Grafico' that would act as a regular *.archimate file (e.g. CTRL+S to save) would be best solution for US.

Sorry but this is not planned for the moment.

pijalu commented 5 years ago

Could it then be possible to have Graphico functionalities separated from modelrepository (and have it build on top) instead of merged ?

This would allows users to decide themselves for the best approach for SC

jbsarrodie commented 5 years ago

Could it then be possible to have Graphico functionalities separated from modelrepository (and have it build on top) instead of merged ?

Now that we have the model repository (ie. Collaboration) plugin for Archi we'll not maintain two codebase, so the original Grafico plugin will not be maintained. The only thing I'm planning (but don't have time to do for the moment) is to expose basic export to/import from Grafico format features in the collaboration plugin. So this will match the original features of the Grafico plugin, nothing more, nothing less.

This would allows users to decide themselves for the best approach for SC

Most users of Archi don't know at all what SC is. The Grafico plugin was just a temporary hack (or a POC) and there are a lot of edge cases that are not managed in Grafico, so using it directly with git (or any SC) commands often leads to screwed models.

Here's just an example:

  1. A model is made available through a git repository. Let's assume this model contains an Actor named "X". This actor is not used in any views.
  2. Two users clone the repo and edit the model.
  3. First user creates a new view "V" that uses actor "X". He then exports, commits and push
  4. Second user notices the unused actor and removes it. He then exports, commits and push. A merge is needed but will succeed without any conflicts.

This sequence results in a corrupted model in which actor "X" has been removed but is still referenced in view "V".

This is one of the cases that is managed on top of git by the Collaboration plugin (in this case it will automatically restore missing element from previous commits).

I guess the real question is: What are your use-cases that justify that you're still using Grafico instead of the Collaboration plugin ?