We have a metric ton of configuration expressed in explicit YANG models which could be generated from YANG annotations.

One example is aaa-app-config.yang, which really could be annotation-driven, if we only defined a corresponding bean in Java and annotate it accordingly.

This amounts to a new feature: given a set of appropriately-annotated classes, we can generate the YANG model which describes them – and Java developers can then design their DTOs in Java without having to know too much about YANG.

Such an annotated class should act as a replacement for things that would normally end up being generated by MD-SAL's binding. That part is just about ready to move back to yangtools, pending removal of per-module notification and RPC interfaces. The interaction here should be such that the generated YANG uses well-defined extensions, which in turn the binding codegen recognizes and instead of generating code it just replaces references to the corresponding Java class.

That means, in turn, that we should have something like:

module odl-yangtools-beans {
  extension java-class {
    argument fqcn {
      // perhaps with a pattern, parhaps a typedef
      type strings;
    }
  }

MD-SAL codegen should recognize this extension as meaning that specified FCQN supersedes anything we would generate. How exactly we bridge from DOM is a question: perhaps we need to generate enough metadata for mdsal-binding-dom-codec to do the right thing.