Custom Preferences when Generating HTML Report through CLI

[Phil Beauvoir]

Try a simpler command that loads an existing *.archimate file and creates the report:

Code Select Expand

Archi.exe -application com.archimatetool.commandline.app -consoleLog -nosplash --loadModel "path_to\\model_name.archimate" --html.createReport "path_to\\folder"


[Eric Vendeville]

Just tested, using the following command-line :

Code Select Expand

Archi.exe -application com.archimatetool.commandline.app -consoleLog -nosplash --loadModel "E:\sysapp\Archi\test.archimate" --html.createReport "E:\test"
Result : Without any surprise (I already tested that few days ago), everything is OK, my custom default colors are correctly applied to the views !

The problem occurs when you try to generate the HTML report from a repository that contains only .xml files (generated by coArchi and synced from git), without any .archimate file in it... hence my assumptions at the beggining of the post, in my 1st message 

[Phil Beauvoir]

The problem occurs when you try to generate the HTML report from a repository that contains only .xml files (generated by coArchi and synced from git), without any .archimate file in it... hence my assumptions at the beggining of the post, in my 1st message

OK, I tested that too and it's also working:

Code Select Expand

Archi -application com.archimatetool.commandline.app -consoleLog -nosplash --modelrepository.loadModel "path_to_coArchi_Folder" --html.createReport "output_folder"

Are you sure the model in the coArchi repo has actually got elements in it that are set to use default colours?

[Phil Beauvoir]

It may be that the model you are using in coArchi has the element fill colours set explicitly to the standard fill colours so that your custom colours are not used.

You could create a very simple test model with one element in it that uses your custom colour and create a repo from that to test.

Or, for a technical deep-dive:

1. Go to the location of the coArchi model and locate one of its diagram XML file named like this - model-repository\repo-name\your-model\diagrams\ArchimateDiagramModel_id-1e04b80c5c1c2152948f132149bea3b1.xml, and open it in a text editor.

2. Check each <children> XML tag and you may see an attribute like fillColor="#ff8040". If this is present then the fill colour is set explicitly for that object and your custom colour will not be used. The custom colour will only be used if the fillColor attribute is not present. Or it will be used for newly created objects if the option "Save the default fill colour for elements in the model file" is set (you have this set in your custom prefs file).

[Eric Vendeville]

Thanks for your last messages Phil, still investigating on my side...

The problem occurs when you try to generate the HTML report from a repository that contains only .xml files (generated by coArchi and synced from git), without any .archimate file in it... hence my assumptions at the beggining of the post, in my 1st message

OK, I tested that too and it's also working:

Code Select Expand

Archi -application com.archimatetool.commandline.app -consoleLog -nosplash --modelrepository.loadModel "path_to_coArchi_Folder" --html.createReport "output_folder"

Are you sure the model in the coArchi repo has actually got elements in it that are set to use default colours?

This command line worked for me (when generating html site from a .archimate project file) :

Code Select Expand

--loadModel "E:\sysapp\Archi\test.archimate"
But not this one (when generating html site from a coArchi git repo... still tried this morning...) :

Code Select Expand

--modelrepository.loadModel "path_to_any_model_structure_synced_from_azure_git_repo"
And yes, I am absolutely sure my coArchi repo has actually elements in it that are set to use default colours (that's to say : elements for which no appearance properties has been manually set).

It may be that the model you are using in coArchi has the element fill colours set explicitly to the standard fill colours so that your custom colours are not used.

You could create a very simple test model with one element in it that uses your custom colour and create a repo from that to test.

Or, for a technical deep-dive:

1. Go to the location of the coArchi model and locate one of its diagram XML file named like this - model-repository\repo-name\your-model\diagrams\ArchimateDiagramModel_id-1e04b80c5c1c2152948f132149bea3b1.xml, and open it in a text editor.

2. Check each <children> XML tag and you may see an attribute like fillColor="#ff8040". If this is present then the fill colour is set explicitly for that object and your custom colour will not be used. The custom colour will only be used if the fillColor attribute is not present.

I already did that "technical deep-dive" before contacting you, and I can assure you that the XML files containing the concerned diagrams (which should render with my custom default colors) do not contain any fillColor="#xxxxxx" property 

[Phil Beauvoir]

I don't think this has anything to do with CLI or coArchi. I think it has something to do with the Appearance colour preference "Save the default fill colour for elements in the model file" which I notice you have set on in your custom preferences file. With this on, any new objects created will save the "fillColor" attribute if the colour for that object is set to "Default".

If a diagram object does not have a "fillColor" attribute set (either in an *archimate file or a coArchi *.xml) then the default color as set in Preferences will be displayed. If the "fillColor" attribute is present then that colour will be displayed.

I've tried creating a coArchi repo with this setting on and off, and with elements containing the "fillColor" attribute and not containing it. I used a fresh install of Archi, a blank location for the "-Dosgi.instance.area" and with your custom_defaults.prefs file. Whatever I try works for me.

I can't diagnose this any further without a model and setup where I can reproduce the problem. I would need to have a copy of an example coArchi repo to do this.

[Eric Vendeville]

...
I think it has something to do with the Appearance colour preference "Save the default fill colour for elements in the model file" which I notice you have set on in your custom preferences file. With this on, any new objects created will save the "fillColor" attribute if the colour for that object is set to "Default".
...

You're right about this option enabled in my preferences file : it was not the case initially, but I must admit that I "played" a bit with it while investigating my problem, in order to better understand how all this "color stuff" works in Archi, and make my own tests...

And I can confirm you that this option works exactly as expected: after being enabled, everey NEW created view correctly uses my "custom default colors" (because, as you said in your previous message, a "fillColor" attribute is "hardly" setted in the XML files, for every element contained in the view).

BUT for all "OLD" views that have been created BEFORE this option has been ticked in my preferences, they (logically) don't embed this "forced" fillColor attribute in the XML files containing the views (i checked that by myself, by opening several XML files for different "old" views)... And then they (theorically) should use my "custom default colors". Instead, the "original default colors" are used.

If a diagram object does not have a "fillColor" attribute set (either in an *archimate file or a coArchi *.xml) then the default color as set in Preferences will be displayed. If the "fillColor" attribute is present then that colour will be displayed.

Unfortunately that's not the case in our environment : the default colors as set in Preferences right after the installation of Archi are used, instead of the default colors as set in our actual Preferences panel.

I can't diagnose this any further without a model and setup where I can reproduce the problem. I would need to have a copy of an example coArchi repo to do this.

I perfectly understand that, and I thank you again for all the time you already wasted trying to help me...
I'm actually trying to build a kind of "MVP" (for Minimal Verifiable Problem  ) and will let you know when done...

Eric

[Phil Beauvoir]

Perhaps you have also changed the colours in Archi itself in Preferences and this is over-riding those declared in "custom_defaults.prefs"?

This would mean that there are some entries in the @user.home/AppData/Roaming/Archi/.metadata/.plugins/org.eclipse.core.runtime/.settings/com.archimatetool.editor.prefs file like defaultFillColour_Resource=\#f13d06

[Eric Vendeville]

Hello Phil,

I'm back to give some news (sorry for the delay... i've been busy with other "higher priority" matters...)

After a few more hours investigating the problem, I finally understood what was happening... and I feel like the ""blame"" is (perhaps ?) to be shared :

• On my side, the paths used in my Archi.ini file (relying on the %user.home% environment variable) did not refer to the directory I was thinking of at first (because the azure agent that run Archi in CLI mode has been deployed by a colleague of mine, then it was (logically) using his %user.home%, not mine... I should have thought of it before...    )
• But on "archi's side", and after fixing the above mentioned problem, I realized that my "packaged version of archi" (with the custom_defaults.prefs), when first executed right after install (either through the GUI or the CLI), do not automatically create/generate the appropriate ~/.archi/.metadata/.plugins/org.eclipse.core.runtime/.settings/com.archimatetool.editor.prefs as (I think) it should... Yet, some other files like ~/.archi/.metadata/.plugins/org.eclipse.core.runtime/.settings/org.eclipse.ui.workbench.prefs (among others...) are well created/generated... so this time, it's no longer a "path resolution" problem...(

I also saw the following discussion on Archi's issues tracker :
https://github.com/archimatetool/archi/issues/1142

It seems like I'm not the only one who has encountered this problem (op finally managed to apply the prefs by manually putting the file in ~/.archi/.metadata/.plugins/org.eclipse.core.runtime/.settings/com.archimatetool.editor.prefs too, as I did).

Not a big deal thoug, we can deal (and live) with it... but maybe this post will help other people facing the same difficulty in the future ! 



 

[Phil Beauvoir]

But on "archi's side", and after fixing the above mentioned problem, I realized that my "packaged version of archi" (with the custom_defaults.prefs), when first executed right after install (either through the GUI or the CLI), do not automatically create/generate the appropriate ~/.archi/.metadata/.plugins/org.eclipse.core.runtime/.settings/com.archimatetool.editor.prefs as (I think) it should.

Hi, no it won't add to that file unless you change the default manually in Archi. It will read that file and preference if it exists, otherwise it defaults to what it finds in custom_defaults.prefs.

[Eric Vendeville]

Thanks for your reply Phil.

OK, i think I understood the expected behavior now.

I (ideally) now have to understand why (when that com.archimatetool.editor.prefs file does not exist) my packaged version of archi refuses to default to the preferences set in my custom_defaults.prefs     

(but I've taken up enough of your time... it will be for next time...  )

[Eric Vendeville]

A last and final post (I promise  ), just because I need to clarify my own last message :

• Archi's GUI works exactly as you depicted (search for com.archimatetool.editor.prefs, and uses custom_defaults.prefs instead if it does not exist... this works fine on my environment : I can indeed see how my custom prefs (defined in custom_defaults.prefs) are loaded and rendered in Archi's Preferences menus)
• Archi's CLI only search for (and work with) com.archimatetool.editor.prefs : it seems to ignore the custom_defaults.prefs) !

I'm pretty sure of myself this time...

[Phil Beauvoir]

Archi's CLI only search for (and work with) com.archimatetool.editor.prefs : it seems to ignore the custom_defaults.prefs) !

It does work. I have it working here.

To test, create a localised copy of Archi 5.6 as follows:

1. Download Archi 5.6 zip version
2. Unzip it somewhere in a folder
3. Replace the Archi.ini file with this:

Code Select Expand

-startup
plugins/org.eclipse.equinox.launcher_1.6.800.v20240513-1750.jar
--launcher.library
plugins/org.eclipse.equinox.launcher.win32.win32.x86_64_1.2.1000.v20240507-1834
-cleanConfig
--launcher.defaultAction
openFile
-pluginCustomization
custom_defaults.prefs
-eclipse.keyring
@user.home/AppData/Roaming/Archi/secure_storage
-vmargs
-Dosgi.requiredJavaVersion=21
-Dfile.encoding=UTF-8
-Declipse.p2.data.area=@config.dir/p2
-Ddata.location=@user.home/Documents/Archi
--add-modules=ALL-SYSTEM
-Dosgi.instance.area=workspace
-Dosgi.configuration.area=workspace/config
-Dorg.eclipse.equinox.p2.reconciler.dropins.directory=%user.home%/AppData/Roaming/Archi/dropins

4. Copy the "custom_defaults.prefs" file into this Archi folder
5. Create a script file called "run.bat" in this Archi folder:

Code Select Expand

Archi -application com.archimatetool.commandline.app -consoleLog -nosplash --modelrepository.loadModel "path_to_archi_repo" --html.createReport "C:\Users\YourName\Desktop\Test"

6. Run the run.bat file

For me this is working and using the colors and settings in "custom_defaults.prefs" (the one you posted here)

[Phil Beauvoir]

I think I know what the problem might be - paths in the Archi.ini file are relative to the directory from where you launch Archi.

If you have the following in your "Archi.ini" file you need to also run Archi from the same directory:

Code Select Expand

-pluginCustomization
custom_defaults.prefs

If you are not running Archi from the same directory in your CLI script, then you need to make it an absolute path something like this:

Code Select Expand

-pluginCustomization
c:/path_to_archi_folder/custom_defaults.prefs

Or you could change directory to the Archi directory in the calling script:

Code Select Expand

cd path_to_archi_folder
Archi -application com.archimatetool.commandline.app....


[Eric Vendeville]

It does work. I have it working here.

To test, create a localised copy of Archi 5.6 as follows:

1. Download Archi 5.6 zip version
2. Unzip it somewhere in a folder
3. Replace the Archi.ini file with this:

...

For me this is working and using the colors and settings in "custom_defaults.prefs" (the one you posted here)

I just tested it this morning : it works for me too !

I think I know what the problem might be - paths in the Archi.ini file are relative to the directory from where you launch Archi.

If you have the following in your "Archi.ini" file you need to also run Archi from the same directory:

Code Select Expand

-pluginCustomization
custom_defaults.prefs

If you are not running Archi from the same directory in your CLI script, then you need to make it an absolute path something like this:

Code Select Expand

-pluginCustomization
c:/path_to_archi_folder/custom_defaults.prefs

Or you could change directory to the Archi directory in the calling script:

Code Select Expand

cd path_to_archi_folder
Archi -application com.archimatetool.commandline.app....


Eureka !   

I followed your tip and tested this in my Archi.ini :

Code Select Expand

-pluginCustomization
c:/path_to_archi_folder/custom_defaults.prefs
...and it works like a charm ! Well done ! (I should have thought of it, shame on me)
(and thanks again for your time and your precious help... I'll sleep better now that I have the key to the mystery  )