Contributing to the new Model Repository Plug-In

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

Previous topic - Next topic

JonSykes

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

Phil Beauvoir

#1
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
If you value and use Archi, please consider making a donation!
Ask your ArchiMate related questions to the ArchiMate Community's Discussion Board.

JonSykes

#2
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. :)

Phil Beauvoir

#3
- 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:



- 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
If you value and use Archi, please consider making a donation!
Ask your ArchiMate related questions to the ArchiMate Community's Discussion Board.

JonSykes


Got it.

Let me see what I can do, might be able to take some of this load off. :)

Phil Beauvoir

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
If you value and use Archi, please consider making a donation!
Ask your ArchiMate related questions to the ArchiMate Community's Discussion Board.

Chris Usher

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

Phil Beauvoir

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
If you value and use Archi, please consider making a donation!
Ask your ArchiMate related questions to the ArchiMate Community's Discussion Board.

Jean-Baptiste Sarrodie

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
If you value and use Archi, please consider making a donation!
Ask your ArchiMate related questions to the ArchiMate Community's Discussion Board.

imteyazbabu

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?

Hervé

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é

Jean-Baptiste Sarrodie

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. Let me know if you need more informations.

Regards,

JB
If you value and use Archi, please consider making a donation!
Ask your ArchiMate related questions to the ArchiMate Community's Discussion Board.

cr0que

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

Jean-Baptiste Sarrodie

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
If you value and use Archi, please consider making a donation!
Ask your ArchiMate related questions to the ArchiMate Community's Discussion Board.

cr0que

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. =)