tadayosi commented on PR #17593: URL: https://github.com/apache/camel/pull/17593#issuecomment-2760279439
@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. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: commits-unsubscr...@camel.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
