Improvements to Command Line Interface

Version of Archi, Operating System
4.1.2 on Windows
Expected Behaviour
When implementing an ICommandLineProvider, it should be possible to set an EXIT status.
Actual Behaviour
Currently the Exit Status is hard coded to "EXIT_OK". The ICommandLineProvider should be extended with a default method (e.g. int getExitStatus()), that can be overriden, to allow also that System.exit(-1) can be handed back to the calling command line party.

How would this work for more than one ICommandLineProvider? As it is, the CentralScrutinizer class calls each one in turn and then returns a single EXIT_OK

In my opinion, an additional parameter for the CentralScrutinizer would be the solution:
continueAtFailure, indicates if processing should continue in case one command line processor fails. Normally the chain would stop if one processor cannot successfully finish his work.
Currently my problem is the following: I run Archi in batch mode to insert models into a Neo4j database via an ICommandLineProvider plugin. In case an insert fails there is currently only log file reading for me to determine what went wrong, but no upfront indication.

I like the idea, I just want to think about the best way to do this.

The CentralScrutinizer's start() method has to exit with EXIT_OK because the other options of EXIT_RESTART, EXIT_RELAUNCH and EXIT_ASYNC_RESULT make no sense here
Could this be achieved by the ICommandLineProvider throwing an exception?

Could this be achieved by the ICommandLineProvider throwing an exception?

The CentralScrutinizer  cound catch all exceptions thrown by each ICommandLineProvider and if continueAtFailure is false then exit.

Maybe no need for "continueAtFailure". If something like an "AbortCommandException" is thrown then exit.

The CentralScrutinizer's start() method has to exit with EXIT_OK because the other options of EXIT_RESTART, EXIT_RELAUNCH and EXIT_ASYNC_RESULT make no sense here

Actually the documentation for start() says:
"Applications can return any object they like.  If an Integer is returned it is treated as the program exit code if Eclipse is exiting."
So, yes that is possible.

Currently I see the following problems:

In case of an AbortCommandException  the Plugin programmer needs to know or guess if the guy that executes my program wants to continue in case of an Exception or not. This might cause a problem in cases where you want to chain plugins or execute multiple plugins on one model. A switch might solve that issue.
Currently there are no means to force an order in the plugin execution (first finds win). Maybe an additional (optional) priority function like int getPriority() ICommandLineProvider could solve that one, so at least you have some sort of fixed order in which the plugins get executed (but this is maybe a differnt issue)

For now I think the exception is a good thing, which will fix my issue without making a breaking code change for existing plugins (as long as AbortCommandException  is a runtime exception. Lateron the two issues above might need to be addressed.

as long as AbortCommandException is a runtime exception

Why? I was thinking of:
       for(ICommandLineProvider provider : providers) {
            try {
                provider.run(args);
            }
            catch(AboutCommandException ex) {
                return -1;
            }
        }

Currently there are no means to force an order in the plugin execution

I agree. I had thought about this and wondered about some kind of chaining mechanism rather than a priority-based approach.

Jep you are totally right, I missed the throws Exception stuff on in the run method.
But I thought you don't want extra command line switches for the CentralScrutinizer class. In this case I would simply catch all Exceptions, because wouldn't Eclipse abort in case of an uncatched exception anyway?

Yes, that's true. I put the "abortFlag" there as an example of usage if there was one.
I think an Exception is a good idea, but not sure whether all outstanding command providers should be aborted if it is thrown. Why should a plug-in make that decision. The user should make that decision, so maybe the "abortFlag" is necessary.

That was my thought as well.

Actually a plugin might throw any exception depending on what it does. At the moment this is thrown onward to the start() method. Should it be the responsibility of the plugin designer to wrap their exceptions in an AbortCommandException or even care about that? Maybe we don't need a special excpetion?

Regarding the sorting/priority issue: Maybe it is a good idea to let the developer give the plugin an initial priority (so you have some kind of order), that can be overridden by an optional property file in the Archi directory.
So if you want one plugin to go first, but do not care about the rest, you could just put in that plugin's Id in the file.

Lets say you have a default function in ICommandLineProvider, that outputs 0 and by which you sort the providers.
I (the plugin developer) override it, because I feel my plugin is super important with 1000.

One other request. Could you take the "helper functions" from HTMLReportCommandLine.java into the CommandLineUtils along the way? They are probably needed by any plugin developer.
- private Map<String, String> parseArgs(String[] args)
- private void logMessage(String message)
- private void logError(String message)

:-)

The least intrusive solution would be an optional -abortOnException flag:
        for(ICommandLineProvider provider : providers) {
            try {
                provider.run(args);
            }
            catch(Exception ex) {
                if(abortOnException) {
                    return -1;
                }
                else {
                    System.err.println(ex);
                }
            }
        }

Sounds good (don't have a "thumbs up" here it seems)

Ahhh. I think I have just been outed as a Github Forum Neeby :-)

private Map<String, String> parseArgs(String[] args)

Not sure how to make that generic. It requires that args come in pairs.

I would propose:
Map<String, String> parseArgs(String[] args, List<String> commandLineNames)
I would only try to find those names in the list and if one is without a value, I would return null as the value string.

Some ideas:

An AbstractCommandLineProvider might be useful for things like the log() methods
A -help switch to return help text, each provider can supply that
The parsing of args could be done by the CentralScrutinizer once and the appropriate args passed to each provider.
Should a provider be interested in all args? If so they can call Platform.getApplicationArgs();
Some options and information for the provider could be added to the plugin.xml declaration - help text, priority, prefix for output log, args that it is interested in

Apache Commons CLI might be useful:
https://commons.apache.org/proper/commons-cli/index.html

Changed title of this issue so we can cover many things.
I think we have to accept that we will break the current API. But it will be worth it,

I also had Apache CLI is a good idea.

I would propose to keep the exsting API functioning if possible and to extend it. I would rather deprecate methods than make a hard break. You could create the AbstractCommandLineProvider implements ICommandLineProvider to have backward compatibility.

An AbstractCommandLineProvider might be useful for things like the log() methods
can be made as a compatible change

A -help switch to return help text, each provider can supply that
can be made as a compatible change. I would split it in two commands:
-help provides a list of available command line plugins with some basic info
help <plugin_name> provides detailed information about the plugin including usage

The parsing of args could be done by the CentralScrutinizer once and the appropriate args passed to each provider.
that is a hard one. I would still opt for the "helper" method to convert the arguments into a map.

Should a provider be interested in all args? If so they can call Platform.getApplicationArgs();
I would think this is a very special case and would not invest extra time in this one

Some options and information for the provider could be added to the plugin.xml declaration - help text, priority, prefix for output log, args that it is interested in
Yep, totally agree. It would be good to have the following informations:
Plugin (unique) name and version as part of the help text
Short description (for the help text)
Usage information with parameter description

Good ideas.
I will create a branch "CLI" here in GitHub and push some experiments. Apache CLI will solve a lot of problems.

Hi guys,
I have one remark regarding the ordering. Why not just use the (JS embedded) script engine so that the command line usage is basically mono-function and one new function being to run a script in which you functions are exposed.
@Phillipus this would be in line with the basic idea of an extendable API for Archi that is usable both from CLI and scripts.

@jbsarrodie Interesting idea. That could be another way to do it. For now, I'm going to improve what we have using Apache CLI. That's an easy win. ;-)

Seems like an interesting idea, but wouldn't that be like creating an own JS "subculture"?
I could image people then solving the same problems in Javascript  and Java, when you do not provide a very clear idea what should be solved where. Also people would start requesting basic Archi functionality like node and model manipulation in Javascript soon.
Currently I find the concept very clear (at least in my view): To extend the functionality a Java plugin should be written on the given extension points. I see the command line interface more like an extension to this concept to allow the plugin to be also run without GUI.
Correct me, if I am wrong on this one.

I've pushed the first code to branch "CLI". @Michael4713 Can you compile and test? Or should I do a test build?

Also people would start requesting basic Archi functionality like node and model manipulation in Javascript soon.

The point is that we already have a working POC of a script engine for Archi. It allows read/write manipulations on model (write being non-undoable though) and comes with nice features. Making plugins available in a way or another has already been discussed but not planed. Time has come ;-)

Seems like an interesting idea, but wouldn't that be like creating an own JS "subculture"?
I could image people then solving the same problems in Javascript and Java, when you do not provide a very clear idea what should be solved where.

This seems clear to me: (JS) scripting should be the way to answer most needs and (Java) plugin should be added when new features are needed. Both should be usable from the command line and plugins should expose their features to the scripting engine.

Currently I find the concept very clear (at least in my view): To extend the functionality a Java plugin should be written on the given extension points. I see the command line interface more like an extension to this concept to allow the plugin to be also run without GUI.

I fully agree. I addition scripting allows model manipulation but also access to plugin features (for example to solve ordering of activities issues).
IMHO I should be able to create a script that:

load a model from a .archimate or exchange format file, from a Git repository (through the model-repository plugin), from a DB (through Herve's DB plugin)...
create a new model and import a CSV
do some manipulation on model, maybe through some dedicated plugins (like the gap analasis one)
export some information to a file/log...
generate an HTML export
generate a Jasper report
....

@Phillipus sure, will try to integrate my plugin tomorrow with the new CLI branch and see if it works.

@jbsarrodie We still need the CLI plugin in order to load "headless"

We still need the CLI plugin in order to run CLI plugins in "headless" mode. So we could combine the JS plugin as well.

Of course yes, a good CLI is needed. My point was just to not try to put too much complexity in it with options to define order of actions, etc...

It's pretty much done. It can't be made non-breaking as it uses Apache CLI and there are new methods and things added to the plugin.xml. It's way better than before.
This:
Archi -consoleLog -nosplash -application com.archimatetool.commandline.app -help]
Prints this:
usage: Archi -application com.archimatetool.commandline.app
       [-abortOnException] [-console] [-consoleLog] [-help] [-nosplash]
 -abortOnException   If present all further command line providers will
                     not run when an exception is thrown
 -console            Enable OSGi console
 -consoleLog         Log output to console
 -help               Show this help
 -nosplash           Don't show the splash screen

Registered plugins:
----------------------

Name: HTML Reports
Description: Generate a HTML Reports from a model file
Usage:
 -HTMLReport_InputFile <file>             Path to the Archi *.archimate model
 -HTMLReport_OutputFolder <path>          Path to the output folder

Name: org.archicontribs.modelrepository.commandlineProvider
Description:
Usage:
 -GenerateHTMLReport_CloneFolder <path>           Path to the Clone Folder
 -GenerateHTMLReport_Password <password>          Password of the repo to clone from
 -GenerateHTMLReport_ReportFolder <path>          Path to the report folder
 -GenerateHTMLReport_URL <url>                    URL of the repo to clone from
 -GenerateHTMLReport_UserName <username>          User Name of the repo to clone from

Why having different options (-HTMLReport_OutputFolder and -GenerateHTMLReport_ReportFolder) for a report generation. Wouldn't it be more simple to dissociate option to load a model (can be from a file, a git repo...), options to generate a report...
Something like:
-LoadModelFromFile <.archimate file>
-LoadModelFromExchangeFile <.xml file>
-LoadEmptyModel
-LoadModelFromCollaborationWorkspace
-LoadModelFromCollaborationURL
-ImportFromCSV
-RunScript
-GenerateHTMLReport
-GenerateJasperReport
-ExportToCSV
-SaveAsFile <.archimate file>
-SaveAsExchangeFIle <.xml file>
etc, etc...

Each command line plugin should be self-sufficient and not dependent on another one so the options need to be namespaced. Also, those options, although they look similar, do different things.

Hmmm...now I'm not so sure. I tried having global options such as -LoadModelFromFile and then each plugin would use the value from that. But then perhaps a command line plugin might want to process a different model if using more than one command...but I suppose you could have more than one invocation...

The problem with using single shared options like -LoadModelFromFile is if you want to call more than one command line plugin and want to work on different models and/or outputs folders.

I liked the idea of having singleton options, so refactored it all to use an OptionFactory of re-usable options.
Now the -help output is:
usage: Archi -application com.archimatetool.commandline.app
       [-abortOnException] [-console] [-consoleLog] [-help] [-nosplash]
 -abortOnException   If present all further command line providers will
                     not run when an exception is thrown
 -console            Enable OSGi console
 -consoleLog         Log output to console
 -help               Show this help
 -nosplash           Don't show the splash screen

Registered plugins:
----------------------

Name: HTML Reports
Description: Generate a HTML Report from a model file
Options:
 -model <file>                 Path to the *.archimate model to use
 -outputFolder <file>          Path to the output folder

Name: Collaboration HTML Report
Description: Generate a HTML Report from a collaboration repository
Options:
 -cloneFolder <path>           Path to the clone folder
 -outputFolder <file>          Path to the output folder
 -url <url>                    URL of the repository to clone from (optional)
 -userName <userName>          User Name of the repository to clone from (optional)
 -password <password>          Password of the repository to clone from (optional)

Needs more work to add plugin specific flags like -GenerateHTMLReport to signal that the plugin should use these options.

That seems better, but I think the way options are shown is confusing: why "-model" is shown under "HTML Report" ? Isn't it a "pure" Archi feature. Same for "-outputFolder" which is related to "HTML Reports" only?
Here is a better explanation of my idea:

We have a generic workflow (with shared interfaces and extension points) and then each plugin can decide to implement (Specialize in ArchiMate terme) some "stages" but only the ones that it really provides. It is then up to the "central" CLI engine to chain all "stages" depending on user needs.
Is-it clearer?

There are no general Archi CLI features. There is only one CLI core plugin, HTML Reports, and one extra CLI plugin, for the Collaboration plugin. They don't know about each other. They do different things. So I don't know how what you are suggesting is possible.

I guess what I called "Archi CLI" is your "CLI core plugin" ? ;-)

They don't know about each other. They do different things.

This is bad, they absolutely have to or else it will not be possible to combine features from different plugins (what if I want to load a model using Herve's DB plugin and then publish it in the (Git) Model Repository)

So I don't know how what you are suggesting is possible.

So I know what I will have to look at for the upcoming days ;-)

The diagram you gave seems more suited to a kind of scripting - do this, then that. But these CLI plugins are discrete one-off actions that require parameters.

This is bad, they absolutely have to

Then it's not possible.

what if I want to load a model using Herve's DB plugin and then publish it in the (Git) Model Repository

More suited to scripting? CLI doesn't load a UI.

The idea is:

To be able to invoke certain features from the CL without the UI launching
To do certain discrete actions by providing parameters
Each CLI plugin is added by the Eclipse-based extension point - therefore the order of loading is not predictable and one extension plugin cannot know about other plugins

Each CLI plugin is added by the Eclipse-based extension point - therefore the order of loading is not predictable and one extension plugin cannot know about other plugins

The order of loading is not important. What is important is to have some sorting of actions depending on "stages". Definition of those stages is done on-off. Let's say that we have this mapping to "priorities" :

LOAD_OR_CREATE_AN_EMPTY_MODEL=10
IMPORT_CONCEPTS=20
RUN_SCRIPT=30
GENERATE_REPORT_OR_EXPORT=40
SAVE_MODEL=50

Then CLI plugins just have to declare the priority of their "features" as 10, 20, 30, 40 or 50. No need to know if other CLI plugins does the same or not. Then (if I understand well) the CentralScrutinizer can sort them (seems to be what the sortedProviders is for) before runing them in order (which seems the main purpose of the Invoke providers' run() method loop).
If not already done, this implies that CLI plugins action all work on current opened model in (headless) Archi.

If not already done, this implies that CLI plugins action all work on current opened model in (headless) Archi.

There is no "current opened model" because each plugin is responsible for loading a model. And each CLI plugin might load it in different way.

And each CLI plugin might load it in different way.

Whatever the way you open/load a model, at the end it is opened and known in Archi so already accessible to other plugins.

There is no "current opened model" because each plugin is responsible for loading a model.

So that's the key ;-)
I'm looking at GenerateHTMLReport. from model repository plugin and this is clearer for me. I now better understand your point.
From what I've seen, it seems that:

Instead of being named GenerateHTMLReport it should be only LoadModelFromModelRepository with an implementation that just load the model in Archi and nothing more.
HTMLReportCommandLine from the Report CLI plugin should use the first currently opened model in Archi instead of CommandLineUtils.loadModel(fileInput).

Of course a CLI plugin would expect to have only one model opened, so should use the first or last one (has to be defined) if multiple have been opened and raise an exception if none is opened.

I tested the new CLI branch with my plugin and it seems to work quite well. Would be cool to see it pushed to master.
Addition:
I enclosed an adapted version of the ICommandLineProvider and the CentralScrutinizer for backward compatibility as suggestion.
public interface ICommandLineProvider {

    String EXTENSION_ID = "com.archimatetool.commandline.commandlineProvider"; //$NON-NLS-1$

    /**
     * Run the command
     * @param commandLine options
     * @throws Exception
     */
    void run(CommandLine commandLine) throws Exception;

    /**
     * @deprecated use run(CommandLine commandLine) throws Exception instead
     */
    @Deprecated
    void run(String[] args) throws Exception;

    /**
     * @return A list of options that this provider supports or null if none
     */
    default Options getOptions() {
    	return null;
    }

    /**
     * @return priority of this provider
     * A value of 0 is the default
     */
    default int getPriority() {
    	return 0;
    }
}

CentralScrutinizer, replacing theprovider.run(commandline)with:
            	try{
            		provider.getClass().getMethod("run", String[].class);
            		// no NoSuchMethodException, so the "old" version is implemented
            		System.err.println("The plugin is still implemeting the old \"run\" method. Please update.");
            		provider.run(Platform.getCommandLineArgs());
            	}
            	catch(NoSuchMethodException nme) {
            		provider.run(commandLine);
            	}

In addition, plugins that expose several features should do it in multiple Classes declared independantly on the plugin registration.

I enclosed an adapted version of the ICommandLineProvider and the CentralScrutinizer for backward compatibility as suggestion.

There's no point. As there are new methods getOptions() and getPriority() in ICommandLineProvider plugins will have to be re-written anyway. They won't work otherwise.

the first currently opened model in Archi instead of CommandLineUtils.loadModel(fileInput).

Where is that?

Where is that? There is no "Archi" running in CLI mode - no tree no editors.

I though we had at least a common list somewhere. What about using CommandLineUtils for that through a static/public method to set/get the currentModel (which would be a private/static attribute) ?

To be clear - when Archi is launched in CLI mode it uses the CentralScrutinizer class which is a headless Eclipse Application. The Workbench is not loaded, and so no Views, nor Editors (all depend on Display and Shell classes). You only have access to the raw components.
When Archi is launched in UI mode then it ties into the workbench with listeners and so on. So the ModelManager keeps track of models loaded in the UI.

What about using CommandLineUtils for that through a static/public method to set/get the currentModel (which would be a private/static attribute) ?

But you can't just hand off to the next CLI plugin as they are discrete. Also, the order of CL options and arguments is arbitrary.

It's a bit like running Unit Tests - each test is independent and knows nothing of other tests.

I enclosed an adapted version of the ICommandLineProvider and the CentralScrutinizer for backward compatibility as suggestion.

There's no point. As there are new methods getOptions() and getPriority() in ICommandLineProvider plugins will have to be re-written anyway. They won't work otherwise.

Actually that might work as you have provided default implementations in ICommandLineProvider (Java 8 feature). I'll add this.

With current implementation, what happens if both htmlreport and model repository cli plugins are installed and you call the cli using both options. Would this load a file and do the report and load a git repo and do the report ?

Would this load a file and do the report and load a git repo and do the report ?

Yes, but not necessarily in that order unless one plugin has a higher priority set.

What you can do is invoke Archi CLI more than once in sequence:
Archi -consoleLog -nosplash -application com.archimatetool.commandline.app -OPTION1
Archi -consoleLog -nosplash -application com.archimatetool.commandline.app -OPTION2
Archi -consoleLog -nosplash -application com.archimatetool.commandline.app -OPTION3

Would this load a file and do the report and load a git repo and do the report ?

There's still an option flag missing that determines whether a plugin should actually be invoked though, when if the correct parameters are present.

From what you describe my idea should work as I expect. I ll be more precise after lunch...

What you want requires:

Preservation of known state
Ordered Sequence

Mostly. Preservation of the model state and ordered sequence but defined by the plugin feature, (through predefined states) not the user.

In addition to the main "cli" branch the collaboration plugin also has a new branch:
https://github.com/archi-contribs/archi-modelrepository-plugin/tree/cli

Back after lunch...
I'll try to better explain what I have in mind.
For the moment Archi plugins that want to provide some CLI features have an added (Eclipse) "commandline plugin" in which their is only one class declared and map to CLI related extension point. This single class manages all command line arguments used by the plugin.
My suggestion is:

change it so that a "commandline plugin" contains several classes (one per "atomic" feature), with each of these classes declared and mapped to the CLI related extension point. This means that an Archi plugin will register multiple instances of this extension point.
add a mandatory "Priority" (or "Stage" or whatever) attribute to the commandlineProvider extension point which will be the basis for the sort of all providers in CentralSrutinizer. Each class declared will then feed this attribute with a (commonly agreed) integer value between:

LOAD_OR_CREATE_AN_EMPTY_MODEL=10
IMPORT_CONCEPTS=20
RUN_SCRIPT=30
GENERATE_REPORT_OR_EXPORT=40
SAVE_MODEL=50

CentralScrutinizer will collect the list of all providers, sort it using the "Priority" attribute and run them all in sequence
CommandLineUtils should be extended as suggested before (static public get/setModel, based on a static private model member)
com.archimatetool.commandline should be extended to add two new classes (following names for illustration only), both registered:

LoadOrCreateModel that will register with "Priority"=10, and will provide a mean to load an existing .archimate file or create an empty model. In each case, this model is then passed to CommandLineUtils.setModel(model)
SaveModel that will register with "Priority"=50, and will provide a mean to save the model to a .archimate file. It will use CommandLineUtils.getModel() for that.

HTMLReportCommandLine in com.archimatetool.reports.commandline should be refactored a bit to not parse command line for model loading arguments and only do its job: generating the HTML report for the model accessible through CommandLineUtils.getModel(). "Priority" should be set to 40.
GenerateHTMLReport in org.archicontribs.modelrepository.commandline should be renamed and refactored to simply load a model from a local or remote repostory and then make it accessible through CommandLineUtils.setModel(model). "Priority" should be set to 10.
etc...

Basically:

each class associated to the commandline entry point should be related to only one stage of the generic workflow, and have the associated "Priority" attribute set.
those classes could manage a set of command line arguments for related but different purposes as soon as they relate to the same "stage" of the generic workflow (e.g. the same class can accept options to load a .archimate model or create an empty model or create a new model from a template)
when parsing command line arguments, those classes should silently ignore arguments they don't use
it's up to the user to make a good use of all provided features.

Some good ideas. I'll try some things and see what works.
We already have a getPriority() method on ICommandLineProvider - not sure if this is better or worse than extension point (at least we don't have to cast a string to integer)

Let's take the example of:

Load a model
Generate a report to a given folder

Now, the user does similar to this:
Archi -blahblah -GenerateHTMLReport -loadModel "test.archimate" -outputFolder "\myfolder"
So the caller only has to declare 3 things (generate, location of model, location of folder), and the plug-in takes care of loading the model and generating the report to target folder.
So in the new way it would be the same command line but:

The core plug-in takes care of -loadModel "test.archimate" and stores to a State class (CommandLineUtils perhaps)
The HTML report plugin takes care of -GenerateHTMLReport and uses -outputFolder "\myfolder"

The core functionality doesn't even need to have an extension point. CentralScrutinizer could manage these.

Hi everyone,
Specifying the actions to be done on the command line requires to manage the priority and it may become a nightmare to someone who whishes to launch several actions..
Why not storing them in a file (let's call this file a script) and just parse it. The commands will then be ran in sequence, one after the other ?

@herve91 Nice idea. There are advantages, but I'll list the cons:

Requires an extra file
File needs to be parsed

I think that the Apache CLI framework keeps the order of the command line options and arguments. So that's another approach - done in the order of the CL.

@herve91 That was one of my remarks (if you find time to read the full thread). My approach is that the CLI should provide some basic/high level workflow that is generic enough for more than 90% of cases. For 8 of the 10% remaining, you can for sure just invoke Archi CLI several time. And for the remaining 2%, we should use a real script plugin (in POC since a long time)..

I think that the Apache CLI framework keeps the order of the command line options and arguments. So that's another approach - done in the order of the CL.

With my approach (generic workflow) I don't see such needs TBH. The order of arguments doesn't really matter as this is common sens that you (for example) have to load a model before generating a report.

So in the new way it would be the same command line but:
[...]
The core functionality doesn't even need to have an extension point. CentralScrutinizer could manage these.

Yes, you get it !

Yes, you get it !

I already got it yesterday. I was just testing you to see if you had the same idea...
...maybe ;-)

First experiments committed and pushed. So far it works. :-)

usage: Archi -application com.archimatetool.commandline.app
       [-abortOnException] [-console] [-consoleLog] [-help] [-loadModel
       <*.archimate file>] [-nosplash]
 -abortOnException               If present all further command line
                                 providers will not run when an exception
                                 is thrown
 -console                        Enable OSGi console
 -consoleLog                     Log output to console
 -help                           Show this help
 -loadModel <*.archimate file>   File path to the Archi model to load.
 -nosplash                       Don't show the splash screen

Registered plugins:
----------------------

Name: HTML Reports
Description: Generate a HTML Report from a model file
Required Options:
 -loadModel <*.archimate file>          File path to the Archi model to load.
Provider Options:
 -createHTMLReport             Create a HTML Report
 -outputFolder <path>          Path to the output folder

Where "Required Options" shows what it needs.

Some remarks

The core functionality doesn't even need to have an extension point. CentralScrutinizer could manage these.

It might be simplier to use extension points in this contexte has at some point we'll have classes for different "workflow stages" (load a model and save a model).

Where "Required Options" shows what it needs.

I don't think this is needed nor even possible: in this example createHTMLReport needs a model to be loaded, but not necessarily using loadModel (can be through model repository, exchange file format, new model then CSV import...).
I would also merge -createHTMLReport and -outputFolder <path> to simply -createHTMLReport <path>.
CommandLineUtils.java has no setModel(model) method, but I guess this is because this is still an experiment.
One question: I don't understand where the priority come from in sortedProviders...

Good comments. More work to do...

One question: I don't understand where the priority come from in sortedProviders...

ICommandLineProvider#getPriority()

ICommandLineProvider#getPriority()

OK, so I guess we could be refactored a bit:
public interface ICommandLineProvider {
    String EXTENSION_ID = "com.archimatetool.commandline.commandlineProvider"; //$NON-NLS-1$
    final int LOAD_OR_CREATE_MODEL = 10;
    final int IMPORT = 20;
    final int RUN_SCRIPT = 30;
    final int REPORT_OR_EXPORT = 40;
    final int SAVE_MODEL = 50;

    [...]

    default int getPriority() {
        return REPORT_OR_EXPORT;
    }
}

Remarks:

TBH I think getPriority should be always redefined.
attribute names (LOAD_OR CREATE_MODEL...) should be better, but you get the idea
We might swap priority of REPORT_OR_EXPORT and SAVE_MODEL as one might argue that you should save as soon as changes are done (and generating a report or exporting to CSV does not change the model).

Hey guys - the "cli" branch has been squashed and rebased onto the latest master head. Also the Eclipse target is now set at 4.7.2. You may need to pull again, and refresh archi.target Target Platform...

New stuff pushed to the "cli" branch and also to https://github.com/archi-contribs/archi-modelrepository-plugin/tree/cli
It all works!
Let the tweaking begin...

More stuff added. Looking good...

usage: Archi -application com.archimatetool.commandline.app -consoleLog
       -nosplash [-abortOnException] [-help]
 -abortOnException   If present all further command line providers will
                     not run when an exception is thrown
 -help               Show this help

Registered plugins:
----------------------

Name: Load Empty Model
Description: Load Empty Model
Options:
 -loadEmptyModel          Load an empty model

Name: Load model from a local repository
Description: This is a local model for local people
Options:
 -loadModelFromLocalRepository <path>          Load a model from the repository folder <path>

Name: HTML Reports
Description: Generate a HTML Report from a model file
Options:
 -createHTMLReport <path>          Create a HTML Report from the current model to folder in <path>

Name: Clone Model
Description: Clone Model from online repository
Options:
 -cloneModel <url> <path>          Clone a model from <url> to folder <path>
 -userName <userName>              Repository user name
 -pwd <password>                   Repository password

Name: Load Model
Description: Load Model from File
Options:
 -loadModel <*.archimate file>          Load a model at given file path.

This seems almost perfect. Some comments though:

It's maybe related to my unix background but I find it strange to have long name option with only one hyphen at start and camel case instead of kebab case.
It's maybe (again) related to my unix background but I find it strange to have an option with two arguments (-cloneModel <url> <path>).
As every plugin will see all command line options, plugin developpers will have to make sure theyr use different options name. We might think about a naming convention.
In this help content, it might be useful to list plugin using their priority so that all model loading options are grouped (for example).
In this help content, it might be useful to find a more compact way of listing available options (see suggestion below).

usage: Archi -application com.archimatetool.commandline.app -consoleLog -nosplash [-abortOnException] [-help]

Common Options:
----------------------
 -abortOnException   If present all further command line providers will
                     not run when an exception is thrown
 -help               Show this help

Registered plugins:
----------------------
[Load Empty Model] Load Empty Model
[Load model from a local repository] This is a local model for local people
[HTML Reports] Generate a HTML Report from a model file
[Clone Model] Clone Model from online repository
[Load Model] Load Model from File

Available options:
----------------------
 -loadEmptyModel                   Load an empty model
 -loadModel <*.archimate file>     Load a model at given file path.
 -loadModelFromLocalRepository <path>          Load a model from the repository folder <path>
 -cloneModel <url> <path>          Clone a model from <url> to folder <path>
 -userName <userName>              Repository user name
 -pwd <password>                   Repository password
 -createHTMLReport <path>          Create a HTML Report from the current model to folder in <path>

...I find it strange to have long name option with only one hyphen at start and camel case instead of kebab case.

OK, open to suggestions...

...I find it strange to have an option with two arguments (-cloneModel  ).

OK, open to alternatives...

As every plugin will see all command line options, plugin developpers will have to make sure theyr use different options name. We might think about a naming convention.

OK, open to suggestions...

In this help content, it might be useful to list plugin using their priority so that all model loading options are grouped (for example).

Done

In this help content, it might be useful to find a more compact way of listing available options

Done:
usage: Archi -application com.archimatetool.commandline.app -consoleLog -nosplash [options...]

Common options:
---------------
 -abortOnException          If present all further command line providers will not run when an exception is thrown
 -help                      Show this help

Registered plugins:
-------------------
[Load Empty Model] Load Empty Model
[Load model from a local repository] This is a local model for local people
[Clone Model] Clone Model from online repository
[Load Model] Load Model from File
[HTML Reports] Generate a HTML Report from a model file

Options:
----------
 -loadEmptyModel          Load an empty model
 -loadModelFromLocalRepository <path>          Load a model from the repository folder <path>
 -cloneModel <url> <path>          Clone a model from <url> to folder <path>
 -pwd <password>                   Repository password
 -userName <userName>              Repository user name
 -loadModel <*.archimate file>          Load a model at given file path.
 -createHTMLReport <path>          Create a HTML Report from the current model to folder in <path>

Here's a real test showing that the order of options doesn't matter:
Archi -consoleLog -nosplash -abortOnException -createHTMLReport "c:\temp\report" -userName<EMAIL_ADDRESS>-pwd "secret" -cloneModel "https://bitbucket.org/xxxx/archi-demo.git" "c:\temp\clone"
This is the output from stringing these commands together:
[CloneModelFromOnlineRepository] Cloning from'https://bitbucket.org/xxxx/archi-demo.git' to c:\temp\clone
[CloneModelFromOnlineRepository] Model cloned!
[CloneModelFromOnlineRepository] Loading model at'c:\temp\clone'
[HTMLReport] Creating report from 'Demo of Plugin' to 'c:\temp\report'
[HTMLReport] Report generated!
Very nice.

It's maybe (again) related to my unix background but I find it strange to have an option with two arguments (-cloneModel  ).

This way we know that the  and  belong to the -cloneModel option. How else could it be done?

Here are some examples of Eclipse's runtime options:
https://help.eclipse.org/oxygen/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Freference%2Fmisc%2Fruntime-options.html
They use a mixture of single and double hyphen and camel case, and dots.
Maybe we could use dots to namespace them?
core.loadEmptyModel
reports.path
third-party-provider.something

Looking at the API for Apache Commons CLI you're supposed to specify a short option (one hyphen) and, if you want, a long option (two hyphens). So "help" would be:
-h --help

This way we know that the  and  belong to the -cloneModel option. How else could it be done?

We already have -loadModelFromLocalRepository <path> to load a model from a local folder, maybe adding `-cloneModel ' in addition could be enough to specify that we want to clone before. The logic would then be:

check if both options are used
if yes, then check that  is empty or does not exist
do the import and then load the model

Looking at the API for Apache Commons CLI you're supposed to specify a short option (one hyphen) and, if you want, a long option (two hyphens).

This is the usual UNIX approach, but in our case I doubt we could have unique single character options accross all plugins. Maybe only options provided by the "core" plugins (those that come with Archi) should have their shorter equivalent.

Maybe we could use dots to namespace them?

From those examples, I would go for those principles:

single hyphen for one character options (only options from Archi standard distribution)
double hyphen followed by long option name without namespace (only options from Archi standard distribution)
double hyphen followed by namespace, dot, and long option name (for other plugins)
long option name is camel case (somethingLikeThat)
namespace is taken either from the last part of the plugin name (so modelrepository for org.archicontribs.modelrepository) or from the full plugin name using firstletter of each domain part and name of the plugin, separated by hypen. So org.archicontribs.modelrepository becomes o-a-modelrepository.

What do you think?

What do you think?

--IThinkIt'sNearlyChristmasTime

It seems that "-" options is a Java and (mostly) Eclipse thing. Frameworks such as git use "--". If we do choose "--" then we can also have the single character "-" options, like "-h"  for help. But I like your suggestions. I'll make some changes and try it out...

Interesting.
With Apache CLI there are two ways to create an option.
Option option1 = new Option("h", "help", false, "Show this help");
Allows you to use "-h", "-help" and "--help"
Option option2 = new Option("help", false, "Show this help");
Allows you to use only "-help".

So, if you want to have a "--" option you have to have a "-" option as well. Apache calls the "-" option a "short" option, and the "--" option a "long" option. So if you want the long options you have to have the short one as well. Unless you just use the short one and make it longer text.

Also we can use other separators instead of the space:
--userName=SantaClaus

Ok, so we can simplify to:

only long options with single hyphen.
long option name is camel case (somethingLikeThat).
hyphen followed by long option without namespace for options that come with Archi by default.
hyphen followed by namespace, dot, and long option name (for other plugins).
namespace is taken from the last part of the plugin name (so modelrepository for org.archicontribs.modelrepository). People writing plugins will have to make sure this part of the plugin name is unique across all contributed plugins.
options should not take more than 1 argument.
separator between option and argument is space.

OK. But:

options should not take more than 1 argument.

Is still a problem that I can't solve for -cloneModel. Your suggestion above doesn't work as it stands.

Is still a problem that I can't solve for -cloneModel. Your suggestion above doesn't work as it stands.

What's the issue you face ?

A comment. I'm looking at current CLI branch of modelrepository, and for my suggestion to work, both options (load and clone) should be managed by a single classe and not two different one (LoadModelFromLocalRepository and CloneModelFromOnlineRepository).

Damn, Apache CLI doesn't allow dots in option names. Underscore is allowed.

This seems to be a restriction on short option name. Have you tried using long options without short name using options.builder ?

Seems ok on that:
Option option1 = new Option("h", "please.help", false, "Show this help");

I see two ways to declare a long option without a short one:
 Option option1 = new Option(null, "please.help", false, "Show this help");
and
Option option1 = Option.Builder.longOpt("please.help")
.hasArg(false)
.withDescription("Show this help")
.build();

Yeah, I already saw that null works but it played badly with my OCD when printing the help because it shows a gap in the formatting:
Common options:
---------------
 -abortOnException          If present all further command line providers will not run when an exception is thrown
    --help                  Show this help

I guess I could write a custom formatter...

but it played badly with my OCD when printing the help

Is it still a real problem is no options have a short version?
I guess result is the same with option.builder ?

both options (load and clone) should be managed by a single class

Done.
New options:
usage: Archi -application com.archimatetool.commandline.app -consoleLog -nosplash [options...]

Common options:
---------------
 -abortOnException          If present all further command line providers will not run when an exception is thrown
 -help                      Show this help

Registered plugins:
-------------------
[Load Empty Model] Load Empty Model
[Load Model] Load Model from File
[Clone/Load Model] Load and Clone model from repository
[HTML Reports] Generate a HTML Report from a model file

Options:
----------
 -loadEmptyModel          Load an empty model
 -loadModel <*.archimate file>          Load a model at given file path.
    --modelrepository.cloneModel <url>             Clone a model from <url>
    --modelrepository.loadModel <path>             Load a model from the repository folder <path>
    --modelrepository.password <password>          Repository password
    --modelrepository.userName <userName>          Repository user name
    --reports.createHTMLReport <path>          Create a HTML Report from the current model to folder in <path>

[Load Empty Model] Load Empty Model
[Load Model] Load Model from File
These could be combined into one? If path is present load it, otherwise empty?

These could be combined into one? If path is present load it, otherwise empty?

I don't think so. I think that they are mutualy exclusive. In addition I would rename loadEmptyModel to createNewModel with an optional argument for the .architemplate to use. But is it possible to have an optional argument ?

New options:

For the sake of harmonization I would make all options long ones with "--". In addition, "createHTMLReport" being included in Archi by default I don't know if it makes sens to prefix it with "reports".

In addition I would rename loadEmptyModel to createNewModel with an optional argument for the .architemplate to use. But is it possible to have an optional argument ?

Done. Yes.
New output:
usage: Archi -application com.archimatetool.commandline.app -consoleLog -nosplash [options...]

Common options:
---------------
 -a,--abortOnException          If present all further command line providers will not run when an exception is thrown
 -h,--help                      Show this help

Registered plugins:
-------------------
[Load Empty Model] Load Empty Model
[Load Model] Load Model from File
[Clone/Load Model] Load and Clone model from repository
[HTML Reports] Generate a HTML Report from a model file

Options:
----------
    --createEmptyModel <"*.architemplate file">          Create an empty model <optional template>
    --loadModel <*.archimate file>          Load a model at given file path.
    --modelrepository.cloneModel <url>             Clone a model from <url>
    --modelrepository.loadModel <path>             Load a model from the repository folder <path>
    --modelrepository.password <password>          Repository password
    --modelrepository.userName <userName>          Repository user name
    --createHTMLReport <path>          Create a HTML Report from the current model to folder in <path>

--saveModel <path> added

Is-it clearer?

I love that diagram in https://github.com/archimatetool/archi/issues/333#issuecomment-353290656
We need to agree on what we have now before I add any more CLI providers.

"CLI" branch commits squashed and rebased onto latest master.
Added Export and Import CSV.
Import from CSV has a lot of options, feel free to suggest different naming convention:
usage: Archi -application com.archimatetool.commandline.app -consoleLog -nosplash [options...]

Common options:
---------------
 -a,--abortOnException          If present all further command line providers will not run when an exception is thrown
 -h,--help                      Show this help

Registered plugins:
-------------------
 [Create Empty Model] Create an empty model from optional template
 [Clone/Load Model] Load and Clone model from repository
 [Load Model] Load Model from File
 [Import from CSV] Import from CSV to current model
 [HTML Reports] Generate a HTML Report from a model file
 [Export to CSV] Export to CSV file format
 [Save Model] Save Model to File

Options:
----------
   --createEmptyModel <*.architemplate file>          Create an empty model <optional template>
   --modelrepository.cloneModel <url>             Clone a model from <url>
   --modelrepository.loadModel <path>             Load a model from the repository folder <path>
   --modelrepository.password <password>          Repository password
   --modelrepository.userName <userName>          Repository user name
   --loadModel <*.archimate file>          Load a model at given file path.
   --importFromCSV <elements.csv file>          Import into the current model in CSV format from <file>
   --createHTMLReport <path>          Create a HTML Report from the current model to folder in <path>
   --csv.delimiter <delimiter>            Delimiter to use for CSV - ",", ";" or "\t"
   --csv.encoding <encoding>              CSV Encoding - "UTF-8", "UTF-8 BOM" or "ANSI"
   --csv.filenamePrefix <prefix>          Prefix for file names
   --csv.leadingZeros                     Use Excel leading zeros/spaces workaround
   --csv.stripNewLines                    Strip newline characters
   --exportToCSV <path>                   Export the current model in CSV format to <path>
   --saveModel <*.archimate file>          Save a model to given file path.

This seems really good !

feel free to suggest different naming convention

My sole remark would be that dot should be used only for namespace, so:

Either we consider that using a namespace for CSV plugin makes sens (even if included by default with Archi) and we use it for every options: --importFromCSV becomes --csv.import, and --exportToCSV becomes --csv.export
Or we don't use a namespace so:

--csv.delimiter becomes --CSVDelimiter
--csv.encoding becomes --CSVEncoding
--csv.filenamePrefix becomes --CSVPrefix
--csv.leadingZeros becomes --CSVLeandingZero
--csv.stripNewLines becomes --CSVStripNewLines

I don't know why but IMO first option (use csv namespace) seems better (less weird)

I don't know why but IMO first option (use csv namespace) seems better (less weird)

I agree.
BTW - just because I'm a saddo doing this on Boxing Day doesn't meant you have to! Get back to your vacation! ;-)

I tried it and the csv.* options all got mixed up and not clear whether they belonged to import or export. So maybe to make it clearer use csv,export.*:
   --createEmptyModel <*.architemplate file>          Create an empty model <optional template>
   --modelrepository.cloneModel <url>             Clone a model from <url>
   --modelrepository.loadModel <path>             Load a model from the repository folder <path>
   --modelrepository.password <password>          Repository password
   --modelrepository.userName <userName>          Repository user name
   --loadModel <*.archimate file>          Load a model at given file path.
   --csv.import <elements.csv file>          Import into the current model in CSV format from <file>
   --createHTMLReport <path>          Create a HTML Report from the current model to folder in <path>
   --csv.export <path>                           Export the current model in CSV format to <path>
   --csv.export.delimiter <delimiter>            Delimiter to use for CSV - ",", ";" or "\t"
   --csv.export.encoding <encoding>              CSV Encoding - "UTF-8", "UTF-8 BOM" or "ANSI"
   --csv.export.filenamePrefix <prefix>          Prefix for file names
   --csv.export.leadingZeros                     Use Excel leading zeros/spaces workaround
   --csv.export.stripNewLines                    Strip newline characters
   --saveModel <*.archimate file>          Save a model to given file path.
``

So maybe to make it clearer use csv,export.*

Prefixing using export is OK but this shouldn't be another namespace. Why not just --csv.exportDelimiter, --csv.exportEncoding, --csv.exportFilenamePrefix, --csv.exportLeadingZeros and --csv.exportSTripNewLines ?

Yep. Better idea.
Pushed.

Regarding export to Jasper - this one has many options:
Path to output
Template path (if not set maybe use the default customisable one?)
Locale
PDF Format
HTML Format
RDF Format
DOCX Format
PPT Format
ODT Format
Suggestions?
--createJasperReport "/path" --jasperTemplate "/path" --jasperLocale "fr_FR" --jasperPDF --jasperHTML --jasperRDF
Or for all the formats in one option, maybe something like --jasperFormat "PDF HTML RDF"?

Or for all the formats in one option, maybe something like --jasperFormat "PDF HTML RDF"?

It seems we can set valueSeparator (the character value used to split the argument string, that is used in conjunction with multipleArgs e.g. if the separator is ',' and the argument string is 'a,b,c' then there are three argument values, 'a', 'b' and 'c'.) to any character. I would suggest "," for that so this would become --jasperFormat PDF,HTML,RDF.
In this case I also think using namespace might be more appropriated:

--jasper.createReport
--jasper.template (optional, defaults to customizable report)
--jasper.locale (optional, defaults to system locale)
--jasper.format (I'd suggest to make it optional and default to PDF, a little bit opiniated but seems to be the most frequent use case)

Jasper Reports added.
usage: Archi -application com.archimatetool.commandline.app -consoleLog -nosplash [options...]

Common options:
---------------
 -a,--abortOnException          If present all further command line providers will not run when an exception is thrown
 -h,--help                      Show this help

Registered plugins:
-------------------
 [Create Empty Model] Create an empty model from optional template
 [Clone/Load Model] Load and Clone model from repository
 [Load Model] Load Model from File
 [Import from CSV] Import from CSV to current model
 [HTML Reports] Generate a HTML Report from a model file
 [Export to CSV] Export to CSV file format
 [Jasper Reports] Generate a Jasper Report from a model file
 [Save Model] Save Model to File

Options:
----------
   --createEmptyModel <*.architemplate file>          Create an empty model <optional template>
   --createHTMLReport <path>                          Create a HTML Report from the current model to folder in <path>
   --csv.export <path>                                Export the current model in CSV format to <path>
   --csv.exportDelimiter <delimiter>                  Delimiter to use for CSV - ",", ";" or "\t" (optional, default is ",")
   --csv.exportEncoding <encoding>                    CSV Encoding - "UTF-8", "UTF-8 BOM" or "ANSI" (optional, default is "UTF-8",)
   --csv.exportFilenamePrefix <prefix>                Prefix for file names (optional)
   --csv.exportLeadingZeros                           Use Excel leading zeros/spaces workaround (optional)
   --csv.exportStripNewLines                          Strip newline characters (optional)
   --csv.import <elements.csv file>                   Import into the current model in CSV format from <file>
   --jasper.createReport <path>                       Create Jasper Reports from the current model to folder in <path>
   --jasper.filename <name>                           File name to use for reports
   --jasper.format <format>                           Comma separated output formats - PDF,HTML,RTF,PPT,ODT,DOCX (optional, default is PDF)
   --jasper.locale <locale>                           Locale in en_GB format (optional, default is system locale)
   --jasper.template <main.jrxml>                     Full path to the main.jrxml template file (optional, default is Customisable Report)
   --jasper.title <title>                             Title of report
   --loadModel <*.archimate file>                     Load a model at given file path.
   --modelrepository.cloneModel <url>                 Clone a model from <url>
   --modelrepository.loadModel <path>                 Load a model from the repository folder <path>
   --modelrepository.password <password>              Repository password
   --modelrepository.userName <userName>              Repository user name
   --saveModel <*.archimate file>                     Save a model to given file path.

Open Exchange Format Import/Export done
usage: Archi -application com.archimatetool.commandline.app -consoleLog -nosplash [options...]

Common options:
---------------
 -a,--abortOnException          If present all further command line providers will not run when an exception is thrown
 -h,--help                      Show this help

Registered plugins:
-------------------
 [Create Empty Model] Create an empty model from optional template
 [Clone/Load Model] Load and Clone model from repository
 [Load Model] Load Model from File
 [Import from CSV] Import from CSV to current model
 [Import from Open XML format] Import from Open XML format
 [HTML Reports] Generate a HTML Report from a model file
 [Export to CSV] Export to CSV file format
 [Jasper Reports] Generate a Jasper Report from a model file
 [Export to Open XML format] Export to Open XML format
 [Save Model] Save Model to File

Options:
----------
   --createEmptyModel <*.architemplate file>          Create an empty model <optional template>
   --createHTMLReport <path>                          Create a HTML Report from the current model to folder in <path>
   --csv.export <path>                                Export the current model in CSV format to <path>
   --csv.exportDelimiter <delimiter>                  Delimiter to use for CSV - ",", ";" or "\t" (optional, default is ",")
   --csv.exportEncoding <encoding>                    CSV Encoding - "UTF-8", "UTF-8 BOM" or "ANSI" (optional, default is "UTF-8",)
   --csv.exportFilenamePrefix <prefix>                Prefix for file names (optional)
   --csv.exportLeadingZeros                           Use Excel leading zeros/spaces workaround (optional)
   --csv.exportStripNewLines                          Strip newline characters (optional)
   --csv.import <elements.csv file>                   Import into the current model in CSV format from <file>
   --jasper.createReport <path>                       Create Jasper Reports from the current model to folder in <path>
   --jasper.filename <name>                           File name to use for reports
   --jasper.format <format>                           Comma separated output formats - PDF,HTML,RTF,PPT,ODT,DOCX (optional, default is PDF)
   --jasper.locale <locale>                           Locale in en_GB format (optional, default is system locale)
   --jasper.template <main.jrxml>                     Full path to the main.jrxml template file (optional, default is Customisable Report)
   --jasper.title <title>                             Title of report
   --loadModel <*.archimate file>                     Load a model at given file path.
   --modelrepository.cloneModel <url>                 Clone a model from <url>
   --modelrepository.loadModel <path>                 Load a model from the repository folder <path>
   --modelrepository.password <password>              Repository password
   --modelrepository.userName <userName>              Repository user name
   --saveModel <*.archimate file>                     Save a model to given file path.
   --xmlexchange.export <path>                        Export the current model in Open Exchange XML format to <path>
   --xmlexchange.exportFolders                        Specifies that folder structure should be exported as an organization structure
   --xmlexchange.exportLang <lang>                    Two letter language code for export. Example - en, fr, de
   --xmlexchange.import <*.xml file>                  Import XML Exchange from <file> and set to current model

Wooo ! Seems really nice... and powerful !

Now let's agree on option names and descriptions and I'll create a beta build and get some feedback via the Archi forum. (String externalisation in the code will wait until this is agreed)

Improved descriptions:
usage: Archi -application com.archimatetool.commandline.app -consoleLog -nosplash [options...]

Common options:
---------------
 -a,--abortOnException          If present all further command line providers will not run when an exception is thrown
 -h,--help                      Show this help

Registered providers:
---------------------
 [Create Empty Model] Create an empty model and set to the current model (from optional template)
 [Load & Clone Collaboration Model] Load and/or clone from a local or online collaboration repository and set to the current model
 [Load Model] Load a model from file and set to the current model
 [Import from CSV] Import data from CSV into the current model
 [Import from Open Exchange XML format] Import from an Open Exchange XML format file and set to the current model
 [HTML Reports] Generate a HTML report from the current model
 [Export to CSV] Export the current model to CSV file format
 [Jasper Reports] Generate Jasper Reports from the current model
 [Export to Open Exchange XML format] Export the current model to the Open Exchange XML file format
 [Save Model] Save the current model to file

Options:
--------
   --createEmptyModel <*.architemplate file>          Create an empty model and set to the current model. If <*.architemplate file> is set,
                                                      this will be used as the model's template.
   --createHTMLReport <path>                          Create a HTML Report from the current model to the folder set at <path>.
   --csv.export <path>                                Export the current model in CSV format to the given path.
   --csv.exportDelimiter <delimiter>                  Delimiter to use for CSV export. One of "," ";" or "\t" (optional, default is ",")
   --csv.exportEncoding <encoding>                    Encoding to use for CSV export. One of "UTF-8", "UTF-8 BOM" or "ANSI" (optional,
                                                      default is "UTF-8",)
   --csv.exportFilenamePrefix <prefix>                Prefix for file names to use for CSV export (optional).
   --csv.exportLeadingZeros                           Use Excel leading zeros/spaces workaround for CSV export (optional).
   --csv.exportStripNewLines                          Strip newline characters for CSV export (optional).
   --csv.import <elements.csv file>                   Import into the current model in CSV format from the supplied elements.csv file.
   --jasper.createReport <path>                       Create Jasper Reports from the current model to the folder set at <path>.
   --jasper.filename <name>                           File name to use for Jasper Reports (required).
   --jasper.format <format>                           List of comma separated output formats for Jasper Reports. Any of
                                                      PDF,HTML,RTF,PPT,ODT,DOCX (optional, default is PDF).
   --jasper.locale <locale>                           Locale for Jasper Reports in "en_GB" format (optional, default is the current system
                                                      locale).
   --jasper.template <main.jrxml>                     Full path to the main.jrxml Jasper Reports template file (optional, default is
                                                      Customisable Report).
   --jasper.title <title>                             Title of Jasper Reports (required).
   --loadModel <*.archimate file>                     Load a *.archimate model from file and set to the current model.
   --modelrepository.cloneModel <url>                 Clone a collaboration model from <url> to the <path> set in option
                                                      --modelrepository.loadModel (optional).
   --modelrepository.loadModel <path>                 Load a collaboration model from the given repository folder at <path> (required if
                                                      option --modelrepository.cloneModel) is used).
   --modelrepository.password <password>              Online repository login password (required if option --modelrepository.cloneModel) is
                                                      used).
   --modelrepository.userName <userName>              Online repository login user name (required if option --modelrepository.cloneModel) is
                                                      used).
   --saveModel <*.archimate file>                     Save the current model to a *.archimate file.
   --xmlexchange.export <path>                        Export the current model in Open Exchange XML format to <path>.
   --xmlexchange.exportFolders                        If set the model's folder structure will be exported as an <organization> structure
                                                      (optional).
   --xmlexchange.exportLang <lang>                    Two letter language code for export. Example - en, fr, de (optional).
   --xmlexchange.import <*.xml file>                  Import an XML Open Exchange file and set to the current model.

I've made a new beta build with this in:
https://www.archimatetool.com/dev/beta

The odd one out to me is:
--createHTMLReport
Maybe it should be:
--reports.createReport
?

(required if option --modelrepository.cloneModel) is used).

There's an unwanted closing parenthesis after cloneModel (same for every occurence of this sentense).
In addition, when something is optional I would make the default option/value explicit everywhere (in csv and xmlexchange)

The odd one out to me is:

I see several issues:

the plugin name (reports) is no more really accurate. htmlexport would be better IMHO.
for the moment there's no need for multiple options (but will at some point when users will be able to define their own export templates and thus will have to choose the one to use)

Maybe --createHTMLreport is ok now but will have to be changed in the future (FYI I'm working on a fully redesigned HTML export template based on modern web technologies -vue.js and Quasar framework- that will include query and dataviz)

Corrections pushed.
Regarding --createHTMLreport - if you are working on a new template (cool!) then maybe we do need a nice prefix now so we don't have to change.  Maybe something that aligns with --jasper.createReport? Like --html.createReport?

FYI I'm working on a fully redesigned HTML export template based on modern web technologies -vue.js and Quasar framework- that will include query and dataviz

You could build a whole app with that!

You could build a whole app with that!

Yes, that's also part of the idea. In short: html export would "dump" model (including folders and views) in an asql database and export each views to images. The "report app" (what I call Archi Web Client) would then allow to:

show views and concepts properties
navigate through the model concepts in a tabular way (select a type of object, add filters, add "property" columns...)
do some SQL and graph based queries (thanks to alasql)
do some dataviz. First using a rawgraphs instance opened in an iFrame. Then maybre create a rawgraphs clone using vuejs

The next step would be to make this app aware of GitHub/BitBucket/GitLab.... API to add enhanced features for those using the collaboration plugin:

add/show comments (ie. issues)
show old version of views (simply load old images in a carousel)
manage repositories...


Updating @angular-devkit/build-angular to 12.2.1 causes styles.css Error

Description
Updated my app from Angular 11.1.1 to the newest stable version (= 12.2.1): ng update @angular/cli.
(
I found it weird that this alone also updated @angular/core. Updating @angular/core explicitly with ng update @angular/cli@12 @angular/core@12 caused the CLI to install @angular/forms and other packages with version 13.0.0-next.1. An issue which was reported but closed.
)
Error
This caused the following error when I tried to start the application: styles.css - Error: (0 , _identifier.getUndoPath) is not a function.
Additional Info
Found a stackoverflow thread where the accepted answer is to downgrade @angular-devkit/build-angular.
=> Downgrading @angular-devkit/build-angular to 12.1.4 indeed fixes the issue.

This seems like a bug but we'll need to look at a reproduction to find and fix the problem. Can you setup a minimal repro please?
You can read here why this is needed. A good way to make a minimal repro is to create a new app via ng new repro-app and adding the minimum possible code to show the problem. Then you can push this repository to github and link it here.
This might be related to your directory structure so its really important to get an accurate repro to diagnose this.

After unsuccessfully trying to reproduce this issue on a clean project, I came to the conclusion that the issue is most likely due to a faulty package-lock.json. If anybody else has this issue, try deleting your node modules and your package-lock.json and reinstall.


Create the v1 launch demo

In your wildest dreams, what demo would be the most awesome to see on MeiliSearch? The biggest wow factor for you, even if you think it's not possible right now with the product we have. What is the ONE thing that would feel like there is a party in heaven made exclusively for your eyes when you check the demo of our new version... Be wild! Be creative! Think outside of the box!
Thinking about v1 launch, we should update the main demos to have something even more amazing and huge. Preferably something with a proper size of information per document and with one field being something visual (image or video...).

I would love to be able to search through the lyrics of the rolling stone magazine top 500 music album and having the autoplay on, but I am not sure we would have the right to do something like this 😢
Maybe if I connect with my Spotify account? 🤷

I would love to be able to search through the lyrics of the rolling stone magazine top 500 music album and having the autoplay on, but I am not sure we would have the right to do something like this 😢
Maybe if I connect with my Spotify account? 🤷

I would love to be able to search in a massive dataset like the 115m+ songs from discogs.com. It would be great to show users that we can search, facet, and filter on a massive amount of data now, that this is no more a problem.
I also thought about being able to search in your whole Twitter history, liked, retweeted, or even just "seen" tweets. I know that it would be a little bit more complex to develop as we need the user's Twitter account.

I would love to be able to search in a massive dataset like the 115m+ songs from discogs.com. It would be great to show users that we can search, facet, and filter on a massive amount of data now, that this is no more a problem.
I also thought about being able to search in your whole Twitter history, liked, retweeted, or even just "seen" tweets. I know that it would be a little bit more complex to develop as we need the user's Twitter account.

I would like to have search on fake data. Like 50M fake users for a CRM like, or search on GitHub users.
It would be also so cool to have search on Wikipedia (need massive machines), but only index few things like the title, and the first paragraph.
Some random idea, search on Pokémon or a card game like D&D, It could be fun for the designer.

I would like to have search on fake data. Like 50M fake users for a CRM like, or search on GitHub users.
It would be also so cool to have search on Wikipedia (need massive machines), but only index few things like the title, and the first paragraph.
Some random idea, search on Pokémon or a card game like D&D, It could be fun for the designer.

I would love to search in a massive dataset like the 115m+ songs from discogs.com. It would be great to show users that we can search, facet, and filter on a massive amount of data now, that this is no more a problem.
I also thought about being able to search in your whole Twitter history, liked, retweeted, or even just "seen" tweets. I know that it would be a little more complex to develop as we need the user's Twitter account.

Seconding this, I would love to see how Meilisearch could compete with Elasticsearch when searching through large datasets that contains billions of data. Would be great to have performance benchmarks and how fast indexing is compared to competitors.

I would love to search in a massive dataset like the 115m+ songs from discogs.com. It would be great to show users that we can search, facet, and filter on a massive amount of data now, that this is no more a problem.
I also thought about being able to search in your whole Twitter history, liked, retweeted, or even just "seen" tweets. I know that it would be a little more complex to develop as we need the user's Twitter account.

Seconding this, I would love to see how Meilisearch could compete with Elasticsearch when searching through large datasets that contains billions of data. Would be great to have performance benchmarks and how fast indexing is compared to competitors.

Four words: searchable database of memes. Would be difficult since most memes are images, so you would need OCR. But can you imagine being able to quickly find the best meme for any given situation (like Giphy/other GIF keyboards)?

Some random idea, search on Pokémon or a card game like D&D, It could be fun for the designer.

Big +1 to the D&D idea, most of that stuff is text already so it would be easy to make, and could actually be hugely helpful to a niche community.  Database of D&D weapons/objects, for example.

Four words: searchable database of memes. Would be difficult since most memes are images, so you would need OCR. But can you imagine being able to quickly find the best meme for any given situation (like Giphy/other GIF keyboards)?

Some random idea, search on Pokémon or a card game like D&D, It could be fun for the designer.

Big +1 to the D&D idea, most of that stuff is text already so it would be easy to make, and could actually be hugely helpful to a niche community.  Database of D&D weapons/objects, for example.

I would love to search in a massive dataset like the 115m+ songs from discogs.com. It would be great to show users that we can search, facet, and filter on a massive amount of data now, that this is no more a problem.
I also thought about being able to search in your whole Twitter history, liked, retweeted, or even just "seen" tweets. I know that it would be a little more complex to develop as we need the user's Twitter account.

Seconding this, I would love to see how Meilisearch could compete with Elasticsearch when searching through large datasets that contains billions of data. Would be great to have performance benchmarks and showcase about how fast indexing is compared to competitors. (Many articles say that one of the biggest con of Meilisearch is slow indexing on large datasets)

Totally agree as well. Additionally, it would be great to showcase in the same demo:

Query suggestions (that improve over time with analytics)
Sort the search results on the fly (e.g., by createdAt, alphabetically, popularity, relevance, etc.)

With an open-source version of Algolia's "Understand" feature that not only tokenizes but also parses the queries with NLP to produce super relevant results
With a live dashboard that anyone can view with statistics about the demo (e.g., with searches, average search time, most popular queries, most recent searches, average click position on the results, etc.)
With a few videos showing (in real-time) how to get started with MeiliSearch and update the engine. Proof that you can unlock all these features in just 5 minutes.

None of those are easy (or possible) with ANY open-source search engine that I found, so even just one with billions of pieces of data would be impressive. That would be wow.
If you're looking for demos that not only showcase real-world use cases but also ones that highlight the special features of MeiliSearch, create a demo that visually shows how MeiliSearch parses the query and sorts the results. That way, people can visualize the tokenizer and the ranking rules on the fly.
By no means do I expect any of this to happen before v1, just thinking big.

I would love to search in a massive dataset like the 115m+ songs from discogs.com. It would be great to show users that we can search, facet, and filter on a massive amount of data now, that this is no more a problem.
I also thought about being able to search in your whole Twitter history, liked, retweeted, or even just "seen" tweets. I know that it would be a little more complex to develop as we need the user's Twitter account.

Seconding this, I would love to see how Meilisearch could compete with Elasticsearch when searching through large datasets that contains billions of data. Would be great to have performance benchmarks and showcase about how fast indexing is compared to competitors. (Many articles say that one of the biggest con of Meilisearch is slow indexing on large datasets)

Totally agree as well. Additionally, it would be great to showcase in the same demo:

Query suggestions (that improve over time with analytics)
Sort the search results on the fly (e.g., by createdAt, alphabetically, popularity, relevance, etc.)

With an open-source version of Algolia's "Understand" feature that not only tokenizes but also parses the queries with NLP to produce super relevant results
With a live dashboard that anyone can view with statistics about the demo (e.g., with searches, average search time, most popular queries, most recent searches, average click position on the results, etc.)
With a few videos showing (in real-time) how to get started with MeiliSearch and update the engine. Proof that you can unlock all these features in just 5 minutes.

None of those are easy (or possible) with ANY open-source search engine that I found, so even just one with billions of pieces of data would be impressive. That would be wow.
If you're looking for demos that not only showcase real-world use cases but also ones that highlight the special features of MeiliSearch, create a demo that visually shows how MeiliSearch parses the query and sorts the results. That way, people can visualize the tokenizer and the ranking rules on the fly.
By no means do I expect any of this to happen before v1, just thinking big.

Create a Pokedex to search on all Pokemon! Quite fun to design, but not so many documents to manage.

Create a Pokedex to search on all Pokemon! Quite fun to design, but not so many documents to manage.


Multi-table update and delete queries are not supported

Currently, updates and deletes that affect multiple entity tables are not supported
For example, suppose Folder, Document, and SymbolicLink all extend   abstract File, which has a name property, and uses InheritanceType.TABLE_PER_CLASS.
That means that Folder, Document, and SymbolicLink each has it's own DB table, each having a name column.
In order to delete all File entities with name like 'Enron%', rows have to be deleted from all 3 tables.
Fixing this would require something like MultiTableUpdateExecutor and MultiTableDeleteExecutor.

I have an initial, fairly crappy, fix for this in #325.

This problem is fixed, except on DB2, and I'm just waiting for a release of core to merge #325.


WIN + N shortcut not appearing on the shortcut list

Microsoft PowerToys version
0.46.0
Running as admin

[X] Yes

Area(s) with issue?
Shortcut Guide
Steps to reproduce
Opened Shortcut guide with the hotley
✔ Expected Behavior
WIN + N being listed as Open Notifications Panel
❌ Actual Behavior
Not being listed
Other Software
No response

Added to https://github.com/microsoft/PowerToys/issues/179

#179 is the tracking issue for these requests


[Revise logical def] MONDO:0008156

Mondo term (ID and Label)
MONDO:0008156/autosomal dominant osteopetrosis 2
Suggested revision of logical definition
I believe this should be removed from the classes of
unclassified primitive or secondary maculopathy and

hereditary optic neuropathy
Your nano-attribution (ORCID) 0000-0001-7451-446
If you don't have an ORCID, you can sign up for one here

Agreed and we should go further and obsolete similar grouping classes that
have 'unclassified' and disjunctions in the name
On Sat, Dec 26, 2020, 05:46 maglott<EMAIL_ADDRESS>wrote:

Mondo term (ID and Label)
MONDO:0008156/autosomal dominant osteopetrosis 2
Suggested revision of logical definition
I believe this should be removed from the classes of
unclassified primitive or secondary maculopathy and
hereditary optic neuropathy
Your nano-attribution (ORCID) 0000-0001-7451-446
If you don't have an ORCID, you can sign up for one here
https://orcid.org/
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/monarch-initiative/mondo/issues/2494, or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAMMOLMNVQUD572I6CGULTSWXSKFANCNFSM4VJ5UB3A
.

@maglott
I'm Sabrina, a new curator who recently joined the Mondo team.
We will address your issue as soon as possible. Thank you for your patience.
If this is a high priority, please let me know and we can prioritize it. Thank you!


Analytics for tofi and dimensions state (infrastructure state)

Would be nice to have a history of the tofugu executions to know, what the last state of the applied configuration by tofi and dimensions.
For example, what sha/checksum of the tofi (tf code) was applied to -d datacenter:staging1 -d account:test-account and when and by whom?
Than it will be easy to display chart/map of the infrastructure current/last state
Document fields

_id = objectId
account_id = link to accountId
tofiName = name of the executed tofi
date = timestamp of the execution
command = first arg (like init, apply, destroy)
full_command = whole command executed by tofugu (like tofu appy -auto-approve)

Info stored in ToasterDB like
{
  "_id": { "$oid": "66367db93509ca433fdcfb06" },
  "orgname": "demo-org",
  "workspace": "master",
  "tofiname": "vpc",
  "cmdtoexec": "tofu",
  "cmdargs": [
    "-backend-config=bucket=default-tfstates",
    "-backend-config=key=org_demo-org/account_test-account/datacenter_staging1/vpc.tfstate",
    "-backend-config=region=us-east-2"
  ],
  "cmdmainarg": "init",
  "exitcode": { "$numberInt": "1" },
  "dimensions": {
    "account": "test-account",
    "datacenter": "staging1"
  },
  "accountid": "662cab7c5e226819838b01fa",
  "datecreated": {
    "$date": { "$numberLong": "1714846798515" }
  }
}

Will think about it more, not merging now.
Maybe it should be disabled by default and enabled via tofugu config, or somehow else (in account in ToasterDB?).


Munin multi-node fixes

Configure firewalld with new wireguard zone
Configure new firewalld rule to allow munin-node in wireguard zone
Add scraping config to munin master against all ansible hosts
Update munin-node config to allow scraping from any configured wireguard host

/merge


Ignore benign error in node reconciler

Ignore benign error if an update has an out-of-date resource version.

I am trying to test this and I am getting:
1.6566725897840126e+09  INFO    Waiting for cleanup pods to complete. Retrying....      {"controller": "falconnodesensor", "controllerGroup": "falcon.crowdstrike.com", "controllerKind": "FalconNodeSensor", "falconNodeSensor": {"name":"default"}, "namespace": "", "name": "default", "reconcileID": "c675d42a-c41c-4454-b9f1-5ec989b3e112", "DaemonSet": "/default"}

in an infinite loop. Is that something that can be related to this PR?

Not sure how it would be related at all. Is the daemonset-cleanup hung up on a pod?

Not sure how it would be related at all. Is the daemonset-cleanup hung up on a pod?

Right. This issue is not related to this PR.

Closing as this isn't a desired solution.


Fix #321

This is to fix #321

The tests run well under my environment. I have no idea yet why the CI fail here.

Agree. Changes applied.

Could you add a line in the changelog describing the fix?

Sure. Is this a common practice for PR here? As I didn't do this in #312, #318 and #320 .

Agree. Thanks for the suggestions. Changes applied.

@jmkerr do you have any clue of why test_report_current is failing with the changes in this PR? Thanks! :relaxed:

Could you add a line in the changelog describing the fix?

Sure. Is this a common practice for PR here? As I didn't do this in #312, #318 and #320 .

As far as I have seen, it is common practice here.

@jmkerr do you have any clue of why test_report_current is failing with the changes in this PR? Thanks! ☺

This is completely unrelated to the content of the commit, but possibly related to the time the test was run between 00:00 and 01:00 UTC. I'll take a look at the problem and open another issue. (I'm sorry.)

This is completely unrelated to the content of the commit, but possibly related to the time the test was run between 00:00 and 01:00 UTC. I'll take a look at the problem and open another issue. (I'm sorry.)

@jmkerr thank you for your help! If there's some way we can help you out, just say it! :+1:


refactor(component): Small code cleanup

Small code cleanup

@treshugart please review.

@Hotell thank you for the feedback. I made all the requested updates and more. Please review PR.

@treshugart this merge did not publish a new release 4.1.3.
Did I make a mistake with commitizen or do I need to manually release?


Add support for Electron 1.8

https://github.com/electron/electron/releases/tag/v1.8.0

Published as v2.1.1


Update README.md

Update name profile

Changing the name frequently is annoying, I have to sync it to the program and too many changes are not appropriate.


Agent mode error with org.springframework.retry.annotation.RetryConfiguration

Hi, is there any work around for this issue?
I got this error while trying to use agent mode with a @SpringBootTest
 @Configuration classes need to be marked as proxyBeanMethods=false. Found: [org.springframework.retry.annotation.RetryConfiguration]
And there is no version of spring-retry that have this disable.

fix by adding this to pom:
<dependency>       <groupId>org.springframework.retry</groupId>       <artifactId>spring-retry</artifactId>       <version>1.3.1-SNAPSHOT</version>     </dependency>


Bump up version

coverage: 96.76%. remained the same when pulling 16e326fee840b5acba210c8b27b6289548f1917f on bumpup_version into d43f8de05ed2ca6a84537b0e8d8975b27414a182 on 2.0.


Add express-style middleware for node.provide

add middleware in node.provide by use async.series
and add test case for middleware

Coverage decreased (-0.1%) to 99.16% when pulling f16be2b4fa7d06d518f1101e2cd11418f3d5e171 on phantomnat:master into ece66a56fda1c1ff074267d8d342fc89821d0ce1 on jitta:master.

Test not pass... Please investigate


fix sha

#This is a comment Template
when sending a createComment request and passing parameters in the json request at run-time these values will be replaced with the content of the given values
{
  "owner": "scalecube",
  "repo": "status-checks",
  "issue_number": 1,
  "body": "greetings scalecube ppl of github-gateway",
  "a-param": "some value"
}

here is example a-param value: some value

#This is a comment Template
when sending a createComment request and passing parameters in the json request at run-time these values will be replaced with the content of the given values
{
  "owner": "scalecube",
  "repo": "status-checks",
  "issue_number": 1,
  "body": "greetings scalecube ppl of github-gateway",
  "a-param": "some value"
}

here is example a-param value: some value

ccc scalecube some value

ccc scalecube some value

This is a comment Template
when sending a createComment request and passing parameters in the json request at run-time these values will be replaced with the content of the given values
{
  "owner": "scalecube",
  "repo": "status-checks",
  "issue_number": 1,
  "template_url": "https://raw.githubusercontent.com/scalecube/github-gateway/test1/src/examples/comment-template.md",
  "a-param": "some value"
}

here is example a-param value: some value


Issue/7528 add link from discovered resource to discovery resource (#7912)

Pull request opened by the merge tool on behalf of #7912

Merged into branches iso7 in 757bc4453921559c233ac1f790ce22fb89d0f879


Treat numerical problems

We should try to keep the prefix values out of the numerical conversion.
For example: 1 / 2ns should safely convert to 0.5 GHz, i.e. the internal division should be 1/2, not 1/0.000000002

This does not seem relevant anymore now that we use purescript-decimals.


Cargo's temp files cause backup churn on macOS

macOS automatically makes hourly backups. Cargo's build temp files are large and frequently changing, causing gigabytes of redundant data backed up every day.
Because the temp files are in multiple project-relative locations, it's not practical for users to manually exclude all the target folders from backup.
Mac applications generally avoid this problem by using system-designed caches directory, but the issue for it (#1615) seems to be in a stalemate.
So I'm proposing an alternative quick fix that doesn't require changing any paths in Cargo. macOS allows excluding individual directories from backups. I suggest marking target/{build,deps,incremental} as excluded. It can be done with:
[URL setResourceValue: @YES] forKey: NSURLIsExcludedFromBackupKey error:nil];

Sounds like a nifty idea to me!

What do you think about promoting this issue as beginner-friendly ?

For me the question is how to call ObjC method from Cargo. There are various approaches for this. Does Cargo have some crate/macro/.m files for this already?

Perhaps the objc crate could be of assistance?

I've managed to implement marking using the objc crate:
https://gitlab.com/kornelski/exclude_from_backups/blob/master/src/macos.rs
Are you OK adding it as a dependency, or should I copy the code to Cargo?

Either's fine by me, although I'd slightly lean towards just copying it into Cargo as it may change over time. Thanks @pornel!
Out of curiosity, have you confirmed that this does indeed fix the problem?

I've verified that it sets com.apple.metadata:com_apple_backup_excludeItem extended attribute on files and directories, so the call works.
The feature requires macOS 10.8+, so I'll need to disable it on 10.7. Does Rust's CI run on 10.7? I don't have a 10.7 machine to test on.

Does this also solve the backup churn you were noticing?
Also yeah we'll need to work on 10.7 somehow, but it's ok to not add a test for this. Is it possible to just ignore errors on 10.7?

It may fail to link on 10.7. I'd have to use #[linkage = "extern_weak"].

I've verified that it prevents the backup churn (I've manually marked all target dirs, and none were in my latest backup).

I've also got a new implementation using servo/core-foundation-rs, which makes the code shorter.

Ok looks and sounds great to me!


feat(generated): update generator to 3.91.0

Automated PR triggered by new code generation.
feat(generated): update generator to 3.91.0
Generated SDK source code using:

Generator version 3.91.0
Specification version 1.0.0-dev0.1.11
Automation (cloudant-sdks) version 28a2f78

I checked stubs, gauge tests and examples and we don't need to change anything, because we are not testing this part, but using streams for attachments everywhere. We probably should test this, but that's out of scope for this PR


fix(update-profile): add blog to avneesh0612

Fixes Issue

Changes proposed

Check List (Check all the applicable boxes)

[ ] My code follows the code style of this project.
[ ] My change requires changes to the documentation.
[ ] I have updated the documentation accordingly.
[ ] All new and existing tests passed.
[ ] This PR does not contain plagiarized content.
[ ] The title of my pull request is a short description of the requested changes.

Screenshots

Note to reviewers

Looks good to me 🚀. Thanks 🙌


Sharding configuration is not configured locally, and sharding configuration is fully obtained from the reg center。

For English only, other languages we will close it directly.
Please answer these questions before submitting your issue. Thanks!
Which version of Sharding-Sphere do you using?
2.0.3
Which project do you using? Sharding-JDBC or Sharding-Proxy?
Sharding-JDBC
Expected behavior
Sharding configuration is not configured locally, and sharding configuration is fully obtained from the reg center。
Actual behavior
There must be an initial sharding configuration locally
Reason analyze
Steps to reproduce the behavior, such as: SQL to execute, sharding rule configuration, when exception occur etc
For bug report, please MUST provide the reproduce example codes (such as a github link).

duplicate with #698


RemoteNode self.public_address should follow use_public_address

Fixes #2694

It needs to fix the test case to get connection_info, and use address from there. The public_address won't be removed, because there may be other requirements to use it.

It needs to fix the test case to get connection_info, and use address from there. The public_address won't be removed, because there may be other requirements to use it.

Shouldn't those other requirements too use private_address when use_public_address is marked False?

Tested this change in the pipeline: https://dev.azure.com/mariner-org/mariner/_build/results?buildId=338845&view=results
Other than this test_case, there are many more tests which are using node.public_address and hence will be fixed by this change. For example, verify_sriov_add_max_nics and verify_boot_with_debug_kernel. Until now I've found 10 files where this change will fix the usage of private_ip address.

It needs to fix the test case to get connection_info, and use address from there. The public_address won't be removed, because there may be other requirements to use it.

Maybe I am not understanding the difference between class variable public_address and _connection_info.public_address, aren't they same? Shouldn't those other requirements too use private_address when use_public_address is marked False?
I created a draft PR for fixing the test case instead here: #2697

Thank you fixing this! public_address and private_address are information on the remote node. We assumed it's always connect from public address, so they are the same. Now, in some scenarios, it needs to be connected from private address, so the connection info is different now. The connection info doesn't save both public/private address, it's how LISA connects to the remote node.
I'm not sure if we need the public_address in future. So for now, we can always use connection info for new connection in LISA.


try to fix scikit-hep/awkward-array#85

First attempt. I don't have good test cases.

This works for my data.

This works for my data.

The day relies on the formula being right, which I copied from ROOT's TLorentzVector. I'm not sure if the sign, either: you might be doubling its boost. Maybe check to see that the .sum() of the boosted vectors have zero momentum components?
(Yours is the first feedback I've gotten about the boost function, though others may have tried it and not told me what they found.)


SDFGI possible compression issues

Godot version
v4.1.3
System information
Godot v4.1.3.stable.mono - Windows 10.0.19045 - Vulkan (Forward+) - dedicated AMD Radeon RX 6900 XT (Advanced Micro Devices, Inc.; 31.0.22023.1014) - AMD Ryzen 9 5900X 12-Core Processor (24 Threads)
Issue description
Trying to use SDFGI, but I'm getting strange artefacts and incorrect bounce colors. Checked the cascades and the pictures show (I think) the problem.

Any ideas on why this happens?
I've tried loading different scenes with different textures, and it seems to work fine with most assets, but with these specific textures (no matter if they're jpg, bmp or png), it just doesn't work as expected. The textures are quite basic and without a lot of color, and I'm thinking that it might be a compression issue specifically for SDFGI. I've attached the GLB as well, so that others can test.
Steps to reproduce

Setup SDFGI in scene with directional light.
Add entrance.glb into scene
Enable visualization of SDFGI cascades

Minimal reproduction project
entrance.zip

SDFGI doesn't use VRAM compression, so this looks like a more generic type of corruption.

I did some further testing and took some more screens:

Those are the same view, same material, in sdfgi cascade view and normal view.
I set the SDFGI cascades to be a single cascade and changed the cellsize to be 0.02 (very small voxels). You can make out that the "general shape" of the colors are there, but the actual colors are crunched into oblivion. Is there some bias towards more vibrant colors that goes bonkers with such low fidelity textures? I know I've seen biasing towards vibrant colors in other GI implementations to get more pronounced color bleeding effect.

Please upload a minimal reproduction project[^1] to make this easier to troubleshoot. (The ZIP only contains a .glb file, not an entire Godot project.)
[^1]: A small Godot project which reproduces the issue, with no unnecessary files included. Be sure to not include the .godot folder in the archive (but keep project.godot).Drag and drop a ZIP archive to upload it. Do not select another field until the project is done uploading.Note for C# users: If your issue is not Mono-specific, please upload a minimal reproduction project written in GDScript or VisualScript. This will make it easier for contributors to reproduce the issue locally as not everyone has a Mono setup available.

SDFGCornell.zip
Minimal repro

I don't see anything out of the ordinary in https://github.com/godotengine/godot/issues/85058#issuecomment-1819059184:

SDFGI disabled
SDFGI enabled

Remember to disable VRAM compression on the textures in the Import dock by using Lossless compression instead. The textures used are low-resolution, so they don't use much VRAM. That said, this doesn't affect SDFGI appearance in any noticeable manner either way.