Publish yaml schema of design definition on https://www.schemastore.org/json/

[apupier]

it will allow to have validation/completion automatically in several IDEs (including VS Code)

requires to have the Yaml schema available of the design definition #1537

[lburgazzoli]

PR merged on schemastore: SchemaStore/schemastore#1138
don't know when it will be available on https://www.schemastore.org/json

[apupier]

The schema is available on https://www.schemastore.org/json

You can use it in various IDE that are relying on it without specific configuration apart from installing the Yaml extension/plugin, for instance:

VS Code:

Eclipse Che (should work also with CodeReady Workspaces but not tried)

For Eclipse Desktop, it should work with latest snapshot of Wild Web Developer but not tried.

Especially, possible with all client implementations listed here https://github.com/redhat-developer/yaml-language-server#clients

For IntelliJ, you can upvote this issue https://youtrack.jetbrains.com/issue/IDEA-236449 (but given that they are not relying on Language Server protocol, this is a non-trivial task)

[lburgazzoli]

is the auto completion triggered also by the modeline or it is required to use the .camelk.yaml suffix for file names ?

[apupier]

is the auto completion triggered also by the modeline or it is required to use the .camelk.yaml suffix for file names ?

the yaml schema specification is working only based on the file name patterns.

it would be possible to dynamically assign the schema based on the modeline but it would require to implement it in each IDE we want to support.

Allowing to specify the schema inside the data file would allow standalone files without relying on filename but it is not part of the specification priorities: json-schema-org/json-schema-spec#828

Can you precise the use case of not using *.camelk.yaml?

From my little knowledge of Yaml, it seems that Kubernetes world is the only major one that doesn't enforce file name pattern (which is causing a lot of troubles in various IDEs for supporting it). Usually, when yaml is used, a file name pattern is expected.

[lburgazzoli]

We had this discussion already and we added the modeline exactly for the reason to avoid having to add .camelk.yaml|java|groovy|js|xml and afaik, the camel-k support is already either triggered by the file name pattern or by the presence of camel-k in the modeline so imho, the support for the auto completion should work the same way and not requiring a different set-up.

In camel-k the name of the file is used to determine the name of the integration so we would need to remove .camelk.* which is not a huge issue but then it would become inconsistent and source of issues as i.e. a Java route named MyIntegration.camelk.java would trigger an error in the IDE as the name of the file is not the name of the class and in the code and then the use would need to code it's java bits in a different way.

Also, modeline could be used to configure how to locate the schema of the dsl.

[apupier]

We had this discussion already and we added the modeline exactly for the reason to avoid having to add .camelk.yaml|java|groovy|js|xml and afaik, the camel-k support is already either triggered by the file name pattern or by the presence of camel-k in the modeline

it is the case for Camel Language Server. The Json schema support is not provided by the Camel language Server.

so imho, the support for the auto completion should work the same way and not requiring a different set-up.

The support of auto-completion relies on the Json schema specification and the Yaml Language Server. It is not related to the Camel language Server.
Referencing the schema from the file itself would be the correct way to do it but currently the Json Schema specification doesn't specify it and the Yaml Language Server is not allowing it.
The Json schemastore and all toolings relies on file pattern association.

In camel-k the name of the file is used to determine the name of the integration so we would need to remove .camelk.* which is not a huge issue but then it would become inconsistent and source of issues as i.e. a Java route named MyIntegration.camelk.java would trigger an error in the IDE as the name of the file is not the name of the class and in the code and then the use would need to code it's java bits in a different way.

Given that it is possible to provide a specific name using name parameter, I would not expect to be really a problem.
Also, we can always include in examples a specific name in Camel K modeline to have even less probability to hit a potential bug in Camel K.

Also, modeline could be used to configure how to locate the schema of the dsl.

Using a specific modeline for yaml-language-server seems to be the easiest to not rely on the filename. (I have no hope to have the json specification improved, especially on short-term).
Specifying it in the Camel K modeline won't help, as there will still need of all clients to do the mapping with the Yaml language server or to put specific Camel K related code in the Yaml Language Server.

[lburgazzoli]

We had this discussion already and we added the modeline exactly for the reason to avoid having to add .camelk.yaml|java|groovy|js|xml and afaik, the camel-k support is already either triggered by the file name pattern or by the presence of camel-k in the modeline

it is the case for Camel Language Server. The Json schema support is not provided by the Camel language Server.

I know but the UX should be the consistent.

so imho, the support for the auto completion should work the same way and not requiring a different set-up.

The support of auto-completion relies on the Json schema specification and the Yaml Language Server. It is not related to the Camel language Server.
Referencing the schema from the file itself would be the correct way to do it but currently the Json Schema specification doesn't specify it and the Yaml Language Server is not allowing it.
The Json schemastore and all toolings relies on file pattern association.

I never said that it should not follow that path but as we also have the modeline to help understanding that we are dealing with a camel-k dsl, then I don't see why we can't re-use it so the experience would be consistent.

In camel-k the name of the file is used to determine the name of the integration so we would need to remove .camelk.* which is not a huge issue but then it would become inconsistent and source of issues as i.e. a Java route named MyIntegration.camelk.java would trigger an error in the IDE as the name of the file is not the name of the class and in the code and then the use would need to code it's java bits in a different way.

Given that it is possible to provide a specific name using name parameter, I would not expect to be really a problem.
Also, we can always include in examples a specific name in Camel K modeline to have even less probability to hit a potential bug in Camel K.

But it won't solve the Java issue

Also, modeline could be used to configure how to locate the schema of the dsl.

Using a specific modeline for yaml-language-server seems to be the easiest to not rely on the filename. (I have no hope to have the json specification improved, especially on short-term).
Specifying it in the Camel K modeline won't help, as there will still need of all clients to do the mapping with the Yaml language server or to put specific Camel K related code in the Yaml Language Server.

[apupier]

In camel-k the name of the file is used to determine the name of the integration so we would need to remove .camelk.* which is not a huge issue but then it would become inconsistent and source of issues as i.e. a Java route named MyIntegration.camelk.java would trigger an error in the IDE as the name of the file is not the name of the class and in the code and then the use would need to code it's java bits in a different way.

Given that it is possible to provide a specific name using name parameter, I would not expect to be really a problem.
Also, we can always include in examples a specific name in Camel K modeline to have even less probability to hit a potential bug in Camel K.

But it won't solve the Java issue

There is no need of .camelk.java. There is no yaml schema for the Java part. I don't understand why there is an issue.

[apupier]

so imho, the support for the auto completion should work the same way and not requiring a different set-up.

The support of auto-completion relies on the Json schema specification and the Yaml Language Server. It is not related to the Camel language Server.
Referencing the schema from the file itself would be the correct way to do it but currently the Json Schema specification doesn't specify it and the Yaml Language Server is not allowing it.
The Json schemastore and all toolings relies on file pattern association.

I never said that it should not follow that path but as we also have the modeline to help understanding that we are dealing with a camel-k dsl, then I don't see why we can't re-use it so the experience would be consistent.

Reusing the current Camel K modeline means either developing specific code in each IDEs clients or to include specific Camel K code in Yaml language Server. None of that is a good solution on middle and long term.

[apupier]

We had this discussion already and we added the modeline exactly for the reason to avoid having to add .camelk.yaml|java|groovy|js|xml and afaik, the camel-k support is already either triggered by the file name pattern or by the presence of camel-k in the modeline

it is the case for Camel Language Server. The Json schema support is not provided by the Camel language Server.

I know but the UX should be the consistent.

i don't think that it is the most important to have consistent User Experience between the various languages in Camel K. it sounds more important to have consistent User Experience with the language itself.

[apupier]

created https://issues.redhat.com/browse/FUSETOOLS2-564 to track various possibilities to not force usage of file name pattern

[apupier]

What's left on this issue? The original goal was to publish the schema and it is the case https://www.schemastore.org/json

[lburgazzoli]

I think it can be closed