Description

• A prerequisite for static type analysis of the transformation specification is that the types of input fields and output fields are available "AT COMPILE TIME" of the transformation specification. So, at this point, we do not have actual values for the CEL expressions yet.
• After we set up an API to get the JSON schema for internal plugins and external plugins (they already provide their JSON schema during their discovery), we can implement a static type analysis a transformation specification.

Scope

• Implement a go generator using https://github.com/invopop/jsonschema to generate JSON schemas for plugin input and output types (our schemas are static, so a generator makes more sense than calling a generation each time).
• Implement an API on the provider interfaces (e.g. ComponentVersionRepositoryProvider) to expose JSON Schema for both internal and external plugins.
• Extend the plugin implementation with the ability to declare their input and output JSON schema (an input schema has to map to an output schema).

The https://github.com/invopop/jsonschema library is only supposed to be used for the initial schema generation and serialization. Consecutive deserializations and work on the schema is supposed to be done using https://github.com/santhosh-tekuri/jsonschema.
Among other things, this is due to a bug in the invopop library. We would need a FalseSchema.Equal/TrueSchema.Equal function in invopop to fix marshalling. Essentially the unmarshal method is broken, but since you cannot rewrite a pointer receiver it is not fixable.

Starting point for the Generator
Starting point for the Provider API

It is important that the implementation still fits to the prototypes / adrs concept.

What to do:
JSON Schema

• Write a JSON schema generator that can convert runtime.Typed (for example, repositorySpec) to JSON schema.
• The type information (so, type name and aliases - oci, oci/v1, ociRegistry, ociRegistry/v1 have to be encoded into the JSON schema.

Done Criteria

• Code has been reviewed by other team members
• Analysis of existing tests (Unit and Integration)
• Unit Tests created for new code or existing Unit Tests updated
• Integration Test Suite updated (includes deletion of existing unnecessary Integration Test and/or creation of new ones if required)
• Enduser Documentation updated (if applicable)
• Internal technical Documentation created/updated (if applicable)
• Successful demonstration in Review