Recent posts

#1
General Archi Discussion / Re: Pinning hidden folder duri...
Last post by romuald - January 24, 2025, 10:22:17 AM
And working. Thanks  8)
#3
coArchi / Extending current commandline ...
Last post by raimondb - January 23, 2025, 12:55:34 PM
Hi all, I am working on some extra commandline options connected to co-archi.

I have created a new class that extends AbstractCommandLineProvider, but it is not getting triggered. How does the discovery process for these providers work? Is it enough to just have a class in a Jar in the plugin dir that derives from this class or is more needed?
#4
coArchi / Re: Publish Changes - Empty Er...
Last post by etienne-sf - January 23, 2025, 10:51:03 AM
Thank you for this thread, which helped me understanding this issue.

As an additional info: another way to check if the user may push a commit, is to use the gitlab GUI to change an existing file, like the README. This makes useless the local installation of git.

Etienne
#5
General Archi Discussion / Re: Pinning hidden folder duri...
Last post by Phil Beauvoir - January 18, 2025, 19:35:15 PM
Will be implemented in Archi 5.5.
#6
General Archi Discussion / Pinning hidden folder during r...
Last post by FredFlintstone - January 18, 2025, 19:30:43 PM
Thanks for a great tool - really bridging a gab :-)

Is there a way to 'pin' the hidden folder setting so that it will retain setting over multiple restarts of Archi?

My main model contains +1000 relations. I'm using the hide folders feature for the relations folder, but I have to set this hiding folder each time Archi have been started :-(

#7
General Archi Discussion / Re: Best method for adding leg...
Last post by romuald - January 16, 2025, 12:48:04 PM
I am using a model to creat my legends that allow you to have legends like you want.
After, I screenshot which legend I want and save it as an image.
Of course, after, you can combine these images to a nice image.
I first use note to show the image but I found that using specialization is far far better.
I have a specialization with an image and I put it in all my views. Just a copy/past. Ok, it's adding an objet in the view but it's name is Legend...
#8
coArchi / Re: Tips for git level shortcu...
Last post by Jean-Baptiste Sarrodie - January 14, 2025, 18:44:34 PM
Hi,

Quote from: raimondb on January 14, 2025, 11:39:15 AMIs that a safe approach, or can it also be that will git thinks the merge is not conflicting, coarchi does actually need to resolve some more logical conflicts?

That's not safe for the reason you mention: a merge can be non conflicting but leading to an invalid model.

Quote from: raimondb on January 14, 2025, 11:39:15 AMCheck if a branch can be fast forwarded, if so use git and not coarchi

Fast-forward is safe from git because it doesn't create any new commit.

Quote from: raimondb on January 14, 2025, 11:39:15 AMsince the change detection takes quite a lot of time.

That should not be the case... unless you have an antivirus which is not well configured (Archi user folder, especially the "model-repository" one, should not be scanned).

Quote from: raimondb on January 14, 2025, 11:39:15 AMIf above successful, merge master to all branches again

I would instead let Archi remove the branches just after merging them into master, and create them back from git.

Regards,

JB
#9
coArchi / Re: Tips for git level shortcu...
Last post by Phil Beauvoir - January 14, 2025, 11:51:04 AM
Hi,

coArchi does some model checks and object resolving so using git on its own is definitely not recommended. I would say that if you do use git on its own there is no guarantee that the model will be valid.

Phil
#10
coArchi / Tips for git level shortcut wh...
Last post by raimondb - January 14, 2025, 11:39:15 AM
Hi, I am using to Archi to the model across multiple branches, we are using a branch-per-architect and feature-branch kind of mechanism.

This works OK as long as we each time do the process of:
- 1. Merge latest master to branch (sync with master)
- 2. Merge all branches to master
- 3. If above successful, merge master to all branches again

Above process is done on a weekly basis, and during a maintenance window where no other people will be committing changes.

I want to check on which part of the process, I could safely just use the git merge and bypass archi itself, since the change detection takes quite a lot of time.

Shortcuts I was thinking about
A. Check via git if branches are actually ahead of each other (master->feature or other way around), only sync the ones that are not up to date, (first get the latest version via git fetch)
B. Check if a branch can be fast forwarded, if so use git and not coarchi

So in essence, first determine if there will be merge conflicts via git and only use coarchi if that is the case. Is that a safe approach, or can it also be that will git thinks the merge is not conflicting, coarchi does actually need to resolve some more logical conflicts?