Contributing to the new Model Repository Plug-In

Started by JonSykes, October 09, 2017, 21:38:32 PM

Previous topic - Next topic


Never mind! I found the detailed documentation for Archi development. Now plugin is ran along with the tool in debug mode.

/ cr0que


Last night I won my first battle with Eclipse- and JGit-development. A lightweight fight just displaying current branch name in the repository information panel. Yeah! =)

Now I'm trying to figure out how to use my newly won experience. How set is the sprint planning? I'm thinking about creating a new view displaying branches with status.

/ cr0que

Phil Beauvoir

Well done! It's not easy.

I think the problems can be divided into areas:

- Eclipse things - menus, tables, etc. This is not really a pain point since I can usually handle this.
- JGit - this can be a pain point as there is limited documentation so we need to be clear about how to manage master, head, branches, refs, revisions etc
- Serialisation - this is tricky because we are converting from one large xml model to lots of small xml files, one for each object. This is so that git can handle merges and diffs better. The conversion from one model to another can be a pain point (and slow in some cases)
- History table. We need to think about whether this is a problem. Suggest we take the simple approach and display only the history of one branch at a time. Using a branch view with lines will be a project in itself.
- Other problem areas - for example, line endings and proxy servers. These have been recorded in the GitHub Issues tracker.
If you value and use Archi please consider making a donation!


I'm thinking about the History Table. The simple approach seems to be attractive from several point of views. I guess that from a developer point of view there will be a lot of more detailed requirements for viewing revisions in a source code tree. From an architect point of view, I believe from my own perspective, you will work with different architecture assets in more well-defined areas with no need of tracking changes per commit. But that's just based on a vague feeling.

The Eclipse platform itself sets a lot of prerequisites regarding GUI design, flexible in one way but kind of fragmented in another.

I say

  • simple approach with history for one branch at the time with
  • branches info and administration in a panel side by side with Change History.

It seems from my point of view to be a working approach according to current GUI design.

Jean-Baptiste Sarrodie


Quote from: Phil Beauvoir on October 12, 2018, 11:38:08 AM
Well done! It's not easy.

+1  ;)

Quote from: cr0que on October 12, 2018, 10:49:33 AM
How set is the sprint planning?

I'm a bit late on this...

Just a bit of context: current sprints (approx. 10 days each) are being funded by my company (Accenture), and FWIW, previous work on Collaboration plugin were funded by Pole Emploi (french employment center) and Arismore (my previous company, which have since been acquired by Accenture). This means that I have to work a bit on the sprint backlog with some colleagues and clients to make sure we are all aligned on the target before Phil and I can move on with development.

And of course, the goal is to clearly define a MVP on this and not try to implement a big and bloated solution.

My first thoughts on this are (I will copy them on github, so please comment there instead of this forum):

  • Add a way (through Collaboration and contextual menu) to select the current branch. By default only "master" should exist.
  • Change plugin's internals to use this "current branch" instead of master for commit/fetch/pull/push operations.
  • Add option to create new branch
  • Add option to remove branch
  • Add option to merge two branches (and choosing whether one of the branches disappears or nor)


If you value and use Archi please consider making a donation!

Jean-Baptiste Sarrodie

If you value and use Archi please consider making a donation!


Since this post is more of a discussion about development and not a direct input to MVP for the branching feature I continue the discussion here.

As I've been more curious about Archi plugin development I fumbled around a little bit in the code ending up with an example UI for branching. UX is most definitely not my specialty so I took the history view as inspiration and base. I've also managed to publish (push) a model into a branch selected from the terminal, only minor code changes.

So far, I've used the git terminology.

The main issue I'm trying to investigate at the moment, is how to reload the model from the GRAFICO format via the temporary .archimate-file. Any thoughts of how this should be done?

Phil Beauvoir

I'm experimenting with different UI ideas. I'm trying to avoid having another separate Eclipse View for branches, as that would mean there would now be three - Collaboration, History and Branches. If the History View could be re-used it might work. Perhaps a space to the side of the history table or a tab in the View.

For reloading the model, have a look in RefreshAction.
If you value and use Archi please consider making a donation!