Modeline and file-based options on http/github endpoints

[nicolaferraro]

This #1515 introduces new ways to run integrations from the cloud directly.

What about modeline options that can be declared in the remote file?

E.g. the file declares something like:

// camel-k: property-file=application.properties

from("").to("")

Currently file-based options are ignored on remote URLs. But can we do better? ("possibly" avoiding infinite recursion).

[lburgazzoli]

should they follow the same path? i.e.

// camel-k: property-file=github:user/repo/application.properties

[nicolaferraro]

I'd better allow relative paths, so they work both when checking out the repo or running integrations remotely.

[lburgazzoli]

It is a little complex as you don't know what is the relative path, assuming that you can run an integration with multiple sources i.e.

kamel run github:user/repo/Source1.java github:user/repo/common/Customizer.java 

unless the relative path is related to the file being processed but that would add a slightly different behaviour when property-file is used from the CLI vs from the modeline.

[lburgazzoli]

mh, wonder if we should add a working-dir option like:

kamel run \
    --working-dir github:user/repo MyRoute.java \
    --property-file=application.property

would be translated to:

kamel run \
    github:user/repo/MyRoute.java \
    --property-file=github:user/repo/application.property

but it could be smart and detect that all the required bits are also available locally and opt to use them directly

[nicolaferraro]

The current approach, also for local files, is to ignore the current CWD dir in the shell. All file-based modeline options are always relative to the file that contains them. It can be the same for remote files.

So the --working-dir github:user/repo is implicit if you run kamel run github:user/repo/MyRoute.java.

[lburgazzoli]

Yep but my point is that there's a different behaviour for the same option used inside a source and outside the source so property-file=application.properties may related to two different locations depending where the option is used, if that's acceptable I can work on it

[nicolaferraro]

Yep but my point is that there's a different behaviour for the same option used inside a source and outside the source so property-file=application.properties may related to two different locations depending where the option is used, if that's acceptable I can work on it

Oh, yes. I think this difference is already there.

Take a file like ./path/It.java and a property file ./application.properties.

To run the file and link it to the properties, you should run:

kamel run ./path/It.java --property-file application.properties

Because CLI options are not related to the file but to the current location.

But if you want to link it using modeline, you should write this line in the file:

// camel-k: property-file=../application.properties

I don't see it as a big problem, we just need to document it ;)

[lburgazzoli]

I guess we can do both so:

1. if the working-dir is set, all the non absolute paths are relative to the working dir
2. if not set, the non absolute paths are relative to the context (to the file for modeline, to the current cwd for the CLI)

This would also mean that application-property=github:user/rep/path would also be possible from modeline.

I think this would give the max flexibility but maybe it is too much ?

[github-actions]

This issue has been automatically marked as stale due to 90 days of inactivity.
It will be closed if no further activity occurs within 15 days.
If you think that’s incorrect or the issue should never stale, please simply write any comment.
Thanks for your contributions!