Manage dependencies

[nicolaferraro]

When the user executes "kamel run Source.java", he might be using some components not available in camel-core.

In this case, the "kamel" script should create the resource as usual (do not put too much logic into the client), while the operator in the "Initialize" action should scan the source file to find declaration of external maven dependencies.

We can use a simplified way to declare dependencies, such as declaring them in a comment, e.g.

 // k-include: camel-mail

This way we let the user specify everything in a single file. We can switch to something better later (best if recognized by the tooling).

The initializer will add "org.apache.camel:camel-mail" to the list of dependencies in the CR (custom resource).

We should enable the following ways to include dependencies:

• Comment in the source file
• kamel run --dependency camel-mail Source.java
• Putting it direcly in spec->dependency->items by editing the custom resource

We should also allow to disable the auto-discovery via a flag e.g. in "spec->dependencies->autoDiscovery", controlled by a "kamel --auto-dependencies false" client flag.

[lburgazzoli]

Wondering if we start supporting only

• kamel run --dependency camel-mail Source.java
• Putting it direcly in spec->dependency->items by editing the custom resource

Putting doc as a comment is fine but error prone

[nicolaferraro]

I think this is a problem we have in common with FaaS platforms, we should investigate what they do to add dependencies to a function.

I'm thinking that there are not many platforms that allow you to change dependencies on the fly while in --dev mode (edit the source file -> save -> the platform redeploys), most of them just change the compiled source. But, if needed, we will be able also to switch base Docker image if we allow declaring dependencies in the source file.

Btw, I'm ok with implementing the other 2 options until we figure out the best strategy for in-file declaration.

[nicolaferraro]

Implemented explicit declaration.