- Welcome to Archi Forum.
Archi - ArchiMate Modelling
Recent posts
#41
General Archi Discussion / How to Create Custom Icons wit...
Last post by Gemini - March 24, 2024, 22:26:01 PMHello,
I have tried to change the element icons by using Image->Custom property.
However, they are displayed with their original size and background and they don't fit into the element original size on the screen.
Is there any method and tool to implement such an icon for each Archimate element?
Thanks
I have tried to change the element icons by using Image->Custom property.
However, they are displayed with their original size and background and they don't fit into the element original size on the screen.
Is there any method and tool to implement such an icon for each Archimate element?
Thanks
#42
jArchi / Re: Bendpoints
Last post by eljavero - March 22, 2024, 18:54:12 PMThats great !!!
Thank you for your support. JArchi is really a great tool. Lots of fun!!!
Thank you for your support. JArchi is really a great tool. Lots of fun!!!
#43
jArchi / Re: Bendpoints
Last post by Phil Beauvoir - March 22, 2024, 18:33:47 PMHi, yes there is. Please take a look here - https://github.com/archimatetool/archi-scripting-plugin/wiki/Visual-Connections
Phil
Phil
#44
jArchi / Bendpoints
Last post by eljavero - March 22, 2024, 18:31:17 PMHi, is there any api or method to modify bendpoints of a connection when it is recently created?
Thank you in advance,
regards
Thank you in advance,
regards
#45
coArchi / Re: Technical metadata on elem...
Last post by johmut - March 20, 2024, 12:52:05 PMThanks JB,
Sounds promising! I will wait in anticipation ....
KR,
Johan
Sounds promising! I will wait in anticipation ....
KR,
Johan
#46
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
#47
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
#48
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
#49
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
#50
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.