CAMEL-21896: camel-jbang - Allow configuration preset per directory

[Croway]

Added the following options:

• --mergeConfigurations loads the configurations default one ~/.camel-jbang-user.properties and the one in the current directory (if exists) ./.camel-jbang-user.properties, the latter is prioritized. This config is a bit hacky, it is used to preload the configuration before the actual picocli execution, if the argument mergeConfigurations exists, the configurations are merged, and the argument removed before passing the args to Picocli.
• --local Use the configuration in current directory (to be used with camel config commands)

[davsclaus]

I wonder if we need any new options at all. At first glance it seems more complicated and when would you use these options?

I would assume that if there is a local file then its always used and take precedence over the default configuration. That's it.

Are there other CLi tools that has these kind of options and are they also named similar ?

[tadayosi]

Thanks, looks great besides the discussion about the usage of --mergeConfigurations. My reply on the topic follows.

[tadayosi]

The wording should be "Store ... to" instead of "Retrieve ... from" here.

[tadayosi]

"Unset" instead of "Retrieve"

[tadayosi]

"Store ... to" over "Retrieve ... from"

[tadayosi]

Or if we want the same wording for all options, we should consider a more generic wording. Examples:
"Apply configrations to current directoyr", or
"Use local configurations instead of global"?

[tadayosi]

@davsclaus @Croway

I wonder if we need any new options at all. At first glance it seems more complicated and when would you use these options?

If we start heavily using camel config set/get/list commands, we'll soon want this feature. For example, some camel script might require additional deps such as dependency=dev.langchain4j:langchain4j-ollama, but I'm sure we don't want to apply it to every route. The same should apply to, say, max-idle-seconds=1, and logging-category=org.apache.camel=WARN. Those are not something that should be stored globally, but at the same time I'm sure we don't want to repeat all of these for every run for some specific routes. That's when this new feature works out. You can create a specific working directory, set up a local config, and just run camel run <script>.

I would assume that if there is a local file then its always used and take precedence over the default configuration. That's it.

For --mergeConfigurations, I agree with Claus. it's not critical that we merge local and global configs with this use case. It's not a big deal, we can always use local one or global one. If we want to enable global again, simply rm .camel-jbang-user.properties.

On the other hand, if we accept the new feature, --local should be still required, as otherwise there's no authentic way to store those configs locally. It's not cool that we must first define them with camel config set ... and then manually cp ~/.camel-jbang-user.properties ..

Are there other CLi tools that has these kind of options and are they also named similar ?

direnv uses the source_up instruction to refer to the parent config. Similar function but naming is different.

[davsclaus]

Ah sorry yeah sure the CLI tool for camel config should work for both local and global mode.

[davsclaus]

If the goal is to have per project "camel jbang" configuration file then I think it should be

• not a hidden file, so its should be named something ala camel-jbang.properties or camel-jbang-local.properties or camel-jbang-user.properties or some other better name.

• the CLI tool able to modify both local and global options with a --global flag etc.

• make the local option take precedence (if exists) and fallback to global option (if exist)

• make the CLI tool able to show a break-down of the options so you can see whether a option is local or global