Hello all!
This is my first time posting here, but I wanted to introduce myself at least. I am an Enterprise Architect based out of Florida and my team has started to do our modeling exclusively using Archi. We are currently working through our workflow on collaboration and decided to take the new Model Repository Plug-In for a spin. I think it is a good foundation to make a really great collaboration tool.
So I have a few questions... I have reviewed the plug-in code and reviewed a lot of the code around Grafico as well.
- Is there a feature on the road map to implement branching/branch selection?
- I know there is a feature on the road map to handle conflicts on merges, but how have others handled conflicts on merge up to this point?
- This is more of a general (non-technical) question. How have others decided to handle future state in their models?
- Can we help contribute to development on items 1 and 2?
We have some free cycles and are experienced Java developers, so we would love to help contribute to the plug-in as it would benefit our team greatly.
Thanks for your time fellas!
Jon
Hi Jon,
welcome to the forums and thanks for your offer of help.
1. Yes - but first we need a better History View to manage potentially big history lists and the branching UI. jGit has an API to handle this and it is implemented in eGit (git client in Eclipse). I tried to reverse engineer it to extrapolate extricate it from the clutches of the Eclipse SDK but failed to do so. ;-)
2. There is some conflict management already. If you are seeing specific conflict types that are not presently handled you could report them here - https://github.com/archi-contribs/archi-modelrepository-plugin/issues
3. I can't answer that as I don't know
4. Yes please - see my responses above...
Phil
Awesome I would be happy to help tackle the branching feature.
So in regards to branching and the Change History, my guess is you would want a way to display history by branch? is this what you were referring to by a "better History View"?
Are there additional issues with the History View when the change log gets large?
I will take a look at eGit to see if I can determine what you are talking about as well. :)
- In Archi we use the jGit library to do the git-based heavy lifting and connect to a git API - https://www.eclipse.org/jgit/
- There is also an eGit plugin for Eclipse that provides a UI and integration with Eclipse. This sits on top of jGit. It also has a History view that can display branches and tags:
(https://cdn.evbuc.com/eventlogos/3974122/githistory.png)
- We can use jGit to take care of actually creating and managing branches but we definitely need that History view in order to see what's going on. The problem is that it so heavily integrated into the Eclipse SDK API that you would bring in a ton of baggage if you tried to use it as-is (Eclipse resources, listeners, properties, you name it...)
> Are there additional issues with the History View when the change log gets large?
Yes. My current implementation is just a dumb table that loads in all commit entries. If the history log is big, this will choke the system. The eGit History view does some fancy lazy loading.
One thing we're trying to do is to protect the Archi user from having to have too much Git fu.
Phil
Got it.
Let me see what I can do, might be able to take some of this load off. :)
Quote from: JonSykes on October 09, 2017, 23:22:29 PM
Got it.
Let me see what I can do, might be able to take some of this load off. :)
That would be great. :)
Might be good to use an issue on GitHub to track this - https://github.com/archi-contribs/archi-modelrepository-plugin/issues/24
Hi Phil and Jon,
I've been using the Model Repository. At present, as a single user I find the plugin is effective and once set up is unobtrusive to use. Looking beyond single user, the branch/fork/pull Git workflow fills me with dread. Git seems to make version control onerous in a distributed environment. I see lack of familiarity of Git branch/fork/pull concepts being the main barrier to my colleagues adopting this type of workflow.
I have used Subversion heavily for 10 years and find it works well, so adapting to Git may be my personal challenge. Git just seems more quirky.
Two questions I have:
- Could the model repository be adapted for Subversion or is it tightly coupled to the Git workflow?
- Jon, have you had any more thoughts on branching for this plugin? Could I do any beta testing for you?
Thanks for pushing forward on what will become a valuable piece of the Archi toolset.
Chris
Hi Chris,
no plans to use SVN, as 90% of the code is tied to Git. We do plan to make branching simple. I know I mentioned that we need to have an enhanced History tree/table view, but it might be possible to simplify the workflow to only show the current branch in the table and a list of existing branches with simple commands like merge.
Phil
Hi Chris,
The plugin doesn't requires any git knowledge (and that's one principle guiding its development). branches are absolutely not needed in a multi user context (Iḿ using the plugin with several colleagues without it). The goal of branching is to allow you to model different versions of your model without mixing them (e.g. as-is, to-be...).
Regards,
JB
Hi ALl,
I want to know is there step by step installation configuration guide for MOdel repository or database plug in which show How to deploy Archi in Multi user environment , where Many people will have central single Repository or Database to save the model and version control?
Hi,
For the database plugin, you only need to do two things:
- Download the JAR file to Archi's folder on all desktops
- Configure the database credentials on the database plugin's configuration page
If you've got other questions, please do not hesitate to read the wiki in my GitHub site (https://github.com/archi-contribs/database-plugin/tree/master/v2), the plugin help pages, or even open a case on GitHub.
Hope this helps.
Best regards
Hervé
Hi,
Quote from: imteyazbabu on October 07, 2018, 12:05:19 PM
I want to know is there step by step installation configuration guide for MOdel repository or database plug in which show How to deploy Archi in Multi user environment , where Many people will have central single Repository or Database to save the model and version control?
Re the Collaboration (ie Model Repository) plugin, you can find most information on the wiki page (https://github.com/archimatetool/archi-modelrepository-plugin/wiki). Let me know if you need more informations.
Regards,
JB
Reading this thread took me into a dream about the ArchiMate modelling heaven. I summarized some thoughts about versioning of an architecture landscape in terms of architecture related to a VCS.
I really appreciate Archi as both an eye-opener for simplicity of architecture work using ArchiMate as well as being the obvious tool of choice for larger architecture initiatives.
The ArchiMate model in Archi could be defined as a well-defined boundary for a specific architecture initiative. Let's say the ArchiMate model represents the Architecture Landscape as defined in TOGAF. Substantially the means that the landscape will aggregate a set of architectures (Enterprise Strategic Architecture, Architecture Segments and Capability Architectures).
The architecture landscape will over time be built up and transformed. There will always be a currently accepted landscape that consists of all accepted aggregates. Work in progress could in current version of Archi be separated by folders for example in the View base folder, exemplified with Baseline and Target architecture and with aggregates as subfolders. Subfolder aggregates has to be moved when accepted.
However, the design of different architectures will always be a subject of discussions. For that reason, work in progress without an open discussion should not be part of the published architecture landscape. In this perspective Archi currently is missing a vital piece, an implementation of the concept of baseline and target architectures – the workflow that "leveraging relevant architecture assets" as described in TOGAF about the Architecture Development Method (ADM).
Since the Model Repository Collaboration Plugin is based on Git VCS an architecture workflow has to be translated into the Git technical implementation. The default branch name in Git is master. In these thoughts master is translated into accepted architecture landscape. Creating a new baseline or target architecture in the landscape should be separated from the accepted architecture landscape until the aggregated piece is accepted. In a Git vocabulary the work of a new architecture has to be made in a branch. So, a new plugin option "New architecture..." will need to create a new branch from the current position and be set as "Working architecture", thus checked out. However, if some changes are made but not written, work has to be written (committed), moved to the trash (a clean checkout) or put away for continue later (git stash).
The plugin also needs a new option for listing of architectures as well as choose an architecture as current working architecture. Since a lot of ideas often are initiated as new architectures the plugin probably needs a cleaning option for removal of unmaintained initiatives (git push origin –delete architecture_branch). The listing will probably also need to signal architectures with work that has not been published yet (some git-branch-status implementation).
When work is finished with a new architecture (branch) the architecture has to be accepted (merged into master combined all commits into one). If detailed history is important the branch should be kept, otherwise the architecture (branch) could safely be deleted. A clean architecture repository will be easier to navigate through.
Does an architecture workflow need specific versioning with version numbers? From a logical point of view, no. Accepted architecture landscape is the current version that includes all accepted aggregates. Work in progress should in general not be made in accepted architecture landscape (master) but for convenience probably possible (for example minor graphical adjustments). New architectures should be initiated from most recent changes in accepted landscape (HEAD) so creation from an old point won't mean anything. With this clean approach to architecture workflow there are no need of git tagging and the architecture landscape will have an understandable changelog (git log HEAD).
The question is whether it's possible to create _an_ architecture workflow. It's probably not regarding source code development which is the reason for Git being as flexible as it is. Since ArchiMate does not cover the workflow of architecture work the workflow must be retrieved from elsewhere. These thoughts collect terms from TOGAF.
The final piece of my ArchiMate modelling heaven. =)
Thanks for a great job with Archi!
/ cr0que
Hi,
Quote from: cr0que on October 09, 2018, 14:48:22 PM
Reading this thread took me into a dream about the ArchiMate modelling heaven. I summarized some thoughts about versioning of an architecture landscape in terms of architecture related to a VCS.
It seems you'll like our next sprint on Collaboration plugin ;-)
Regards,
JB
Sounds really great!
Since I follow both issue tracker and source code management I have a hint of what's coming.
I'm a former (among other languages java-) developer trying to investigate whether it's possible for med to contribute to the development. I've got an Eclipse-environment up and running, managed to build and run Archi and build Model Repository Collaboration Plugin. Each one individually. Since I've never developed an Eclipse-based application before I got a "small" threshold understanding the big picture. Quite a lot of code...
Can you give me a hint of how to debug an Archi plugin? From where the plugins are initiated? At the moment the collaboration plugin is my main interest as my dream suggests. =)
Never mind! I found the detailed documentation for Archi development. Now plugin is ran along with the tool in debug mode.
/ cr0que
Hi!
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
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.
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.
Hi,
Quote from: Phil Beauvoir on October 12, 2018, 12:38:08 PM
Well done! It's not easy.
+1 ;)
Quote from: cr0que on October 12, 2018, 11: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)
Regards,
JB
Link to issue to define scope for MVP: https://github.com/archimatetool/archi-modelrepository-plugin/issues/67
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?
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.