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

Automatic linking of Camel K schema based on Camel K modeline #279

Closed
apupier opened this issue Jul 15, 2020 · 7 comments
Closed

Automatic linking of Camel K schema based on Camel K modeline #279

apupier opened this issue Jul 15, 2020 · 7 comments

Comments

@apupier
Copy link
Member

apupier commented Jul 15, 2020

Camel K has a specific modeline which allows to identify that a yaml file is a Camel K one.

# camel-k:

They would like to avoid forcing a specific filename (such *.camelk.yaml).

Given that schema cannot be specified inside the file directly. Would it be possible to associate the Camel K schema with files using the modeline # camel-k?

technically, it would be a "simple" matter of modifying

public getSchemaForResource (resource: string, doc = undefined): Thenable<ResolvedSchema> {

From a conceptual point of view, are we ready to have specific code to Camel K in Yaml language server? (there is already specific code for Kubernetes)

this would be last priority for schema resolution #250 (comment)

@JPinkney
Copy link
Contributor

Personally I'm against having specific code for any extension inside of the language server, and instead, want everything to be an API if possible. The only reason why there is kubernetes specific code was that when I was assigned the project ~3 years ago it was originally just a language server for kubernetes files. Eventually, we enhanced everything to include YAML but also kept kubernetes for compatibility.

@gorkem WDYT?

@gorkem
Copy link
Collaborator

gorkem commented Jul 15, 2020

I agree. I would rather have APIs. I am not sure even kubernetes is making a lot of sense anymore, there are extensions out there nowadays that are using the APIs to set k8s schemas better than the fixed setting. It is something that is left over from the early days of the extension.

@apupier
Copy link
Member Author

apupier commented Jul 15, 2020

Personally I'm against having specific code for any extension inside of the language server

me too personally.

there are extensions out there nowadays that are using the APIs to set k8s schemas better than the fixed setting

the problem with this approach is that it requires a specific implementation in each client.

want everything to be an API if possible.
I would rather have APIs.

would be an API to provide a custom "SchemaResolver" written in javascript/TypeScript? How to pass it when the client is not a typescript project? a npm module and the class name?
it would mean that each clien twoudl need to provide it also. But we would have to write the "SchemaResolver" a single time.

@apupier
Copy link
Member Author

apupier commented Jul 16, 2020

want everything to be an API if possible.
I would rather have APIs.

would be an API to provide a custom "SchemaResolver" written in javascript/TypeScript? How to pass it when the client is not a typescript project? a npm module and the class name?
it would mean that each clien twoudl need to provide it also. But we would have to write the "SchemaResolver" a single time.

the CustomSchemaProvider is already available for that?

private customSchemaProvider: CustomSchemaProvider | undefined;

if (this.customSchemaProvider) {
return this.customSchemaProvider(resource)
.then(schemaUri => {
if (Array.isArray(schemaUri)) {
if (schemaUri.length === 0) {
return resolveSchema();
}
return Promise.all(schemaUri.map(schemaUri => {return this.resolveCustomSchema(schemaUri, doc);})).then(schemas =>
{return {
'errors': [],
'schema': {
'anyOf': schemas.map(schemaObj => {return schemaObj.schema;})
}
};}
, err => {return resolveSchema();});
}
if (!schemaUri) {
return resolveSchema();
}
return this.resolveCustomSchema(schemaUri, doc);
})
.then(schema => {return schema;}, err => {return resolveSchema();});

@JPinkney
Copy link
Contributor

If we re-used the custom schema provider I think what we could do is modify it so that if something like:

# some_modeline 

appears in the YAML file then instead of passing in the resource to the customSchemaProvider pass in the modeline. That way any extensions that handle the modeline would pass the schema back.

For example,
If we have vscode apache camel and vscode-yaml installed. vscode apache camel would set up the the client side part of the custom schema provider to say if we are passed camel-k then return the camel schema. Then when the modeline is passed in it automatically resolves the schema

@apupier
Copy link
Member Author

apupier commented Jul 16, 2020

I started work to register a customSchemaProvider camel-tooling/vscode-camelk#483

Sometimes the schema is correctly found and the completion is provided but most of the time not. Currently searching why.

@apupier
Copy link
Member Author

apupier commented Jul 23, 2020

rejected to avoid having Camel K specific code inside Yaml language Server.

@apupier apupier closed this as completed Jul 23, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants