Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Deprecate overlapping Kamel CLI features in favour of Camel JBang #3790

Closed
tadayosi opened this issue Nov 1, 2022 · 5 comments · Fixed by #3839
Closed

Deprecate overlapping Kamel CLI features in favour of Camel JBang #3790

tadayosi opened this issue Nov 1, 2022 · 5 comments · Fixed by #3839

Comments

@tadayosi
Copy link
Member

tadayosi commented Nov 1, 2022

There are overlapping features between Camel K kamel CLI and Camel JBang. To name a few:

  • kamel init vs camel init
  • kamel local run vs camel run
  • kamel bind vs camel bind

We should favour camel over kamel for the overlapping features and drop them from kamel for Camel K 2.0. For now, we should mark them as deprecated.

@tadayosi tadayosi added the area/cli Kamel CLI label Nov 1, 2022
@squakez
Copy link
Contributor

squakez commented Nov 2, 2022

In general I'm in favor to go in that direction. However, for kamel bind I think it may be a bit more complicated because it creates and deploy the Integration. It also manages aspects like traits, properties and tenancy operator to use, so, until there is a complete overlap of the command, I'd avoid to mark it as deprecated.

squakez added a commit to squakez/camel-k that referenced this issue Nov 24, 2022
* kamel local
* kamel init

Closes apache#3790
@squakez
Copy link
Contributor

squakez commented Nov 24, 2022

I've added a PR that will address this issue. However, I have some remarks.

  1. The kamel bind cannot be deprecated because we also take care of deploying the KameletBinding and we do much more advanced configuration than camel bind.
  2. I've deprecated the entire kamel local. I am not entirely sure if the kamel local build or kamel local inspect are actually used by anyone.

@tadayosi
Copy link
Member Author

Thanks! Yes, I agree that camel bind cannot replace kamel bind.

For kamel local, we can deprecate all the commands for sure.

For kamel local inspect, I personally find it useful when debugging to see the expected dependencies are actually there. I would contribute the same feature to camel CLI, and/or move the same command to kamel top-level like kamel inspect as a debugging option for developers.

The reason why I'd think the subcommand is useful for debugging is that it uses the same internal mechanism with kamel run for resolving dependencies from integration files so it could be used as a fast check on whether expected dependencies are detected without uploading to cloud.

Different views are also welcome.

@davsclaus
Copy link
Contributor

You can use camel dependencies to see which dependencies are in use

@tadayosi
Copy link
Member Author

Ah cool. camel dependencies --main-class <file name without extension> does the trick!

@squakez squakez added this to the 1.11.0 milestone Nov 25, 2022
squakez added a commit to squakez/camel-k that referenced this issue Nov 28, 2022
* kamel local
* kamel init

Closes apache#3790
squakez added a commit that referenced this issue Nov 28, 2022
* kamel local
* kamel init

Closes #3790
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants