Generate JSON schema of Flogo app descriptor

[debovema]

Completely inspired by work of @pointlander in https://github.com/project-flogo/microgateway project (see https://github.com/project-flogo/microgateway/tree/e0abd58fba70f73f8bb6e2c68d23f50277700826/internal/schema), I added the required files to generate the JSON schema of the Flogo app descriptor (flogo.json).

This will be very useful to validate against the schema at buildtime / runtime and output the errors to end-users and also to write unit tests.

[debovema]

BTW, you can validate the default flogo.json against the generated JSON schema at https://www.jsonschemavalidator.net for instance.

[debovema]

Is there something missing before merging ?

[fm-tibco]

Hi guys,

There is no doubt that we need to provide the schema, the question is do we need this schema generating code or should we just provide the file? I hope we aren't going to be changing the schema much more going forward... but having the code is nice. @mellistibco @vijaynalawade any thoughts?

[vijaynalawade]

I tend to agree with @fm-tibco. A single schema definition in core repo should be good enough to validate any flogo app json. Things like object schema are under consideration that might need app descriptor update. So, it would be better to keep a file which can be updated easily.

[emilienthomas]

Franck, Vijay,

If the flogo app json changes often, you save time and effort by generating the json schema.
If the flogo app json changes only a few times, generating the schema in the build process ensures that you do not forget to impact the json schema file.

What advantage do you see in not generating the json schema ?

[debovema]

The idea behind this was also to facilitate the writing of unit tests with standard Flogo app descriptor.
If the structures evolve, we automatically ensure that older flogo.json (used by customers) still validate, load and run.

[mellistibco]

I'm not sure why we should generate the schema during build? Why not generate it once and store it in git? We should then look at adding validation to the cli. I'm not sure I see any reason for the schema to generate code in core. If this is just to facilitate unit tests, perhaps the cli can generate whatever code is required via a plugin?

[fm-tibco]

Regardless, the flow and stream actions should also have schema's for their corresponding resources.

I don't think the schema will change much, but the nice thing about this, as part of the travis build, we can generate the schema and if by any chance the schema.json changed, we can catch it there. This assumes the schema generation code generates an identical schema.json if the code hasn't been altered.

[mellistibco]

@debovema what specifically are you thinking? microgateway uses the schema for run time validation, are you thinking the same here?

[debovema]

Validation at runtime could be good. Especially if the validation outputs more readable messages to the end user in case of errors.
But the main advantage I see is to keep a single source of truth. Currently the truth is given by the Go structures (as they will be used to parse actually) and, with your option, generating the JSON separately will be another source of truth uncorrelated to the first one. Hence the 😕

[fm-tibco]

Thats fine, we should also incorporate the validation into the engine as part of startup. What do you mean by validate against the schema during build time? How do you envision this being used in unit tests... do we need to expose a public method given that currently resides in the internal directory?

[fm-tibco]

@debovema Any reason you closed this PR? I was hoping to incorporate your code in core and also in both flow and stream to validate their resources.

[debovema]

Sorry it was a false manipulation with mobile phone.

[debovema]

I am not sure if we can avoid the public method. The package name could be changed though.

[debovema]

I created project-flogo/flow#4 for flow action definition.