Improve IDE compatibility

[nicolaferraro]

It would be awesome if we could define a syntax (groovy or kotlin based) for integrations in such a way that we can configure a IDE for autocompletion.

E.g. a groovy file using grape may import all required libraries.

We may add a builder like the one in this old discussion: https://twitter.com/ro14nd/status/1014124955120951297?s=19

.. to have IDE autocompletion.

Unfortunately, all attempts I've made to find a good combination failed. E.g. grape fails.

Another option I was investigating is to add a command like 'kamel init routes.kts' that generates a initial hello world with a gradle.build file to configure the IDE.

Open to better alternatives. Ideas?

[nicolaferraro]

@lburgazzoli , @astefanutti you may have some hints

[astefanutti]

Not sure that will help as it may be out of the question scope you have in mind, but just to share the info: In OpenShift 4 console, the user will have the ability to instantiate CR managed by installed operators. For instance, user would be able to create integration CR when the Camel K operator is installed via OLM. The console will provide a basic UI at the beginning, with a plain YAML editor, but some people have suggested that LSP could be eventually used, as a way to provide a smarter UI, e.g., with validation, auto-completion, ... It's not there yet, still LSP is used by VS Code and is a reusable layer for other IDE to use. So maybe we could consider extending Java / Groovy / Kotlin LSP with some Camel K features that would become the foundation for Camel K editors / IDE support.

[jcordes73]

IMO it would be good to have a kamel init command, at least for maven and gradle as most IDE's have plugins for those two project setups.

[samuelhnrq]

How about an gradle plugin?

We then try to explain the global scope of groovy, file structure (TBD #1135), and whatnot to the build tool and let whatever first party build tool integration of the IDE do the rest of the magic?

Obvious cons:

• First and foremost, it's probably overkill to involve the elephant that is gradle here:
• it's not even going to build anything
• Confuse developers adding dependencies and not having them reflected

UNLESS we give in to gradle overlords and use it instead of the cli, kamel run as a target, kamel run --dev as another target so on and so forth, test as a target as well, dependencies, configuration with it etc etc. Which I would personally love, huge gradle fan here

EDIT: But I know that would be tremendously drastic, no idea about viability, just brainstorming

[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!