Launch for Camel routes should use * and not the yaml file name

[lhein]

If you want to prototype a route which contains Java files then the current Launch command is not sufficient. The current command is only useful if the user just has a single yaml file that they want to run. I would like to see the launch use the camel run * --dev instead so all the Java files and possible other files are taken into consideration too.

[lhein]

It doesn't help to store the java class under src/main/java.

[apupier]

the current implementation allows to be more precise on which files are launched and avoid side-effects.

An alternative is to use a launch configuration or to provide * as additional parameter with the settings to run and debug (soon to be released).

Note that it is not specific to VS Code Kaoto. it applies to all kind of Camel files and the related code is in VS Code Devug Adapter for Camel

[lordrip]

Couldn't we have an additional button to say "Run container folder"? This way we could have both scenarios covered

[lordrip]

Also, I don't know if it's possible, but could those buttons be a dropdown instead, so we would have both run and debug under the same button, ala IntelliJ?

[apupier]

yes, it is possible to have a dropdown with this quick button menu action on editors.

I think we should keep 2 distincts buttons between run and debug especially if we are providing 2 entries to run single file and run all files.

[lordrip]

That could work as well, as long as we have easy access to the option directly in the file, we're good.

Maybe another thing to consider would be if it's possible to run the file in the folder context, meaning that for that execution, the CWD is the containing folder, this is because this way, the application.properties file would be next to the route, at least in the quick prototyping mode, offering a more flexible way to configure routes, as the opposite that would be having a single application.properties file in the workspace's root

[apupier]

Maybe another thing to consider would be if it's possible to run the file in the folder context, meaning that for that execution, the CWD is the containing folder, this is because this way, the application.properties file would be next to the route, at least in the quick prototyping mode, offering a more flexible way to configure routes, as the opposite that would be having a single application.properties file in the workspace's root.

If I understand well, the idea is to have one folder per integration project and that VS Code is opened on one parent folder having several of this "folder integration project".
If yes, this use case is currently out of scope. The amount of work for supporting completely that is too large compared of the needed work and the resources we have.

Plus if you are already at this stage, the better way to handle it on a real project is to have a multi-module maven project

[lordrip]

Oh, no exactly like that, let me rephrase myself.

Considering the following structure:

my-app/
├─ kafka-consumer/
│    ├─ route.camel.yaml
│    ├─ application.properties
├─ kafka-producer/
│    ├─ route.camel.yaml
│    ├─ application.properties
├─ .gitignore
├─ application.properties

Considering VSCode opening my-app/kafka-consumer/route.camel.yaml, my proposal would be to use the kafka-consumer folder as CWD, this way, the application.properties next to that route would be picked, rather than using the root application.properties.

[apupier]

Oh, no exactly like that, let me rephrase myself.

Considering the following structure:

my-app/
├─ kafka-consumer/
│    ├─ route.camel.yaml
│    ├─ application.properties
├─ kafka-producer/
│    ├─ route.camel.yaml
│    ├─ application.properties
├─ .gitignore
├─ application.properties

Considering VSCode opening my-app/kafka-consumer/route.camel.yaml, my proposal would be to use the kafka-consumer folder as CWD, this way, the application.properties next to that route would be picked, rather than using the root application.properties.

this is unfortunately the structure I meant.

[apupier]

Alternative which is covering more cases and avoids to potentially throw users in not working cases by default:
https://issues.redhat.com/browse/FUSETOOLS2-2368 Provide submenu quick action button to run with all elements
https://issues.redhat.com/browse/FUSETOOLS2-2369 Provide submenu quick action button to run with all elements from containing folder