Dear All,
I am using coArchi for a couple of years now, with a couple of architects working on a shared model repository. Patiently waiting for coArchi 2, I am excited to read there is work being done on a release later this year.
Is there a list of prioritized requirements which we can see, and possibly even add suggestions or comments to?
My pain: I use a 'Note' visual block on every view that shows metadata, maintained as properties on view level.
Examples: Diagram Version Number and Validation Status, Validation Body as well as the typical CreatedBy, CreatedOn, MofifiedBy, ModifiedOn, ChangeLog, ...
Time & Discipline to update these properties manually is sometimes lacking... So i got thinking:
When publishing changes to git using coArchi (2?), is it imaginable to somehow push the datetime, git user and git commit message back to the updated view/element properties? Or is there another way of achieving this ?
Always happy to hear whether and how you guys & girls deal with this.
Hi, you can add feature requests for coArchi 2 here - https://github.com/archimatetool/archi-modelrepository-plugin2/issues
However, given the remaining workload for coArchi 2 (and Archi and jArchi, etc. etc....) I don't think your idea will be implemented any time soon, unless someone else contributes it.
Phil
Hi Phil,
Thank you for your reply.
With coArch2's new approach to store models in git, can you explain in a few words how tracking changes will become simpler? I'm still interested to hear how other coArchi user groups track changes to their models...
Is there a list of prioritized features (a road map) so I can avoid putting in redundant feature requests?
KR,
Johan
Hi,
the road map for coArchi 2 right now is to implement the core features and handle diffs and merging, see https://github.com/archimatetool/archi-modelrepository-plugin2/issues/10 We're not even thinking about anything beyond matching the feature set of coArchi 1 right now.
Phil
Hi,
Quote from: johmut on March 20, 2024, 07:44:24 AMIs there a list of prioritized features (a road map) so I can avoid putting in redundant feature requests?
Not at the moment, but I guess I can write a wiki page for that (as I did when we worked on coArchi 1 back in the days). Don't expect it for next week, but next month seems reasonable.
Quote from: johmut on March 20, 2024, 07:44:24 AMWith coArch2's new approach to store models in git, can you explain in a few words how tracking changes will become simpler? I'm still interested to hear how other coArchi user groups track changes to their models...
The main difference between coArchi1 and coArchi2 is that coArchi1 relies on git to get the list of changes and to do the merge. To ease git's work, the model is saved as a bunch of really small XML files (one per element, relationship or view). Unfortunately, git is not good at merging models and very often the resulting merge is not a valid model (e.g. a change removing an element merged with a change adding a view based on that element doesn't raise any conflicts and leads to a view containing a reference to a now removed element), that's why coArchi1 contains an anti-corruption layer taking care of most of these issues, but some can't be managed (for example the well know "File is not directory or folder.xml does not exist (https://github.com/archimatetool/archi-modelrepository-plugin/wiki/File-is-not-directory-or-folder.xml-does-not-exist)").
CoArchi2 will still rely on git for some simple and straightforward cases, but will use EMFCompare (https://eclipse.dev/emf/compare/) to manage other cases. Because of that :
- It is no more needed to "explode" the model and now git will simply host the .archimate file (with some trick used if the model contains some images).
- EMFCompare understand the model as a whole and is able to link changes so that my previous example (a change removing an element merged with a change adding a view based on that element) is seen as a conflicts.
In addition, because EMFCompare provides an API to access the list of changes, it is quite easy to provide an option so that the user can see what has been changed before they commit, but also to do a diff between two versions of the model.
Other that that, coArchi2 will also come with an enhanced Collaboration Workspace in which you can group models into folders to better organize it.
Regards,
JB
Thanks JB,
Sounds promising! I will wait in anticipation ....
KR,
Johan