- Welcome to Archi Forum.
Archi - ArchiMate Modelling
Recent posts
#31
coArchi / Re: Technical metadata on elem...
Last post by Jean-Baptiste Sarrodie - March 20, 2024, 09:33:32 AMHi,
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.
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").
CoArchi2 will still rely on git for some simple and straightforward cases, but will use EMFCompare 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
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").
CoArchi2 will still rely on git for some simple and straightforward cases, but will use EMFCompare 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
#32
coArchi / Re: Technical metadata on elem...
Last post by Phil Beauvoir - March 20, 2024, 09:11:05 AMHi,
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
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
#33
coArchi / Re: Technical metadata on elem...
Last post by johmut - March 20, 2024, 07:44:24 AMHi 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
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
#34
coArchi / Re: Technical metadata on elem...
Last post by Phil Beauvoir - March 19, 2024, 11:38:26 AMHi, 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
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
#35
coArchi / Technical metadata on elements...
Last post by johmut - March 19, 2024, 11:06:55 AMDear 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.
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.
#36
General Archi Discussion / Re: A database of property obj...
Last post by Azix - March 17, 2024, 20:57:58 PMThanks for the information I've already made a similar script but for example on my firewall I can make object groups.
for example serverweb_group which contains
Server1
Server2
Server3
If I want to make an element group named severweb_group with archimate without putting each object in the view because there can be more than 25 objects in a group. So I'm obliged to take a "Node" for each server and "communication network"? and place them in a Groupings one by one?
for example serverweb_group which contains
Server1
Server2
Server3
If I want to make an element group named severweb_group with archimate without putting each object in the view because there can be more than 25 objects in a group. So I'm obliged to take a "Node" for each server and "communication network"? and place them in a Groupings one by one?
#37
General Archi Discussion / Re: In the model view, can the...
Last post by Xiaoqi - March 16, 2024, 22:02:11 PMHi,
You can see the demo video https://youtu.be/BIUODhE3Ya0 to see how to hide needed folders in model tree, referring to the user guide items that Phil mentioned. FYI...
Xiaoqi
You can see the demo video https://youtu.be/BIUODhE3Ya0 to see how to hide needed folders in model tree, referring to the user guide items that Phil mentioned. FYI...
Xiaoqi
#38
jArchi / Re: Order of a $(selection)
Last post by Phil Beauvoir - March 16, 2024, 12:13:59 PMThe jArchi "selection" variable is taken from the underlying Eclipse global selection and there is no guarantee of the order of elements (and this might be different on Mac and Windows). When you select objects in a View the selection order reflects the order in which you click on them, but in the Models Tree this is not the case, because (as you found) they are sorted alphabetically.
BTW, because the "selection" variable is a collection you don't need to wrap it as in "$(selection)" just use it like "selection.get(0);"
BTW, because the "selection" variable is a collection you don't need to wrap it as in "$(selection)" just use it like "selection.get(0);"
#39
jArchi / Order of a $(selection)
Last post by blayde64 - March 16, 2024, 11:26:35 AMAs i understand it $(selection) is ordered. I wanted to select two views in the model browser, and apply several properties from the first selected object to the second selected one. I had thought this would work:
If i have two views "A" and "B", it doesn't matter if i select A or B first, i always have "A" returned in target object. Is there any way i can programmatically identify the first selected item? ie, not have the selection sorted?
Many thanks.
Code Select
var targetObj = $(selection).get(0);
var sourceObj = $(selection).get(1);If i have two views "A" and "B", it doesn't matter if i select A or B first, i always have "A" returned in target object. Is there any way i can programmatically identify the first selected item? ie, not have the selection sorted?
Many thanks.
#40
General Archi Discussion / Re: Create relation when techn...
Last post by Jean-Baptiste Sarrodie - March 12, 2024, 12:46:09 PMHi,
There is no "defect" here as indeed an application interaction can be realized by technology behavior, but interaction being internal application behavior, it can only be realized by internal technology behavior (ie. function, process or interaction). A service can only realize another service.
Regards,
JB
Quote from: svenvandevelde on March 12, 2024, 09:43:11 AMI would call this actually a functional "defect", as an application interaction can be realized by a specific technology service type.
There is no "defect" here as indeed an application interaction can be realized by technology behavior, but interaction being internal application behavior, it can only be realized by internal technology behavior (ie. function, process or interaction). A service can only realize another service.
Regards,
JB