Operating System: All
Platform: All

Attachment ietf-netconf-monitoring@2010-10-04.yang has been added with description: ietf-netconf-monitoring

Attachment ietf-inet-types@2010-09-24.yang has been added with description: ietf-inet-type

Attachment bug.PNG has been added with description: classes generated in wrong place

YANG (RFC6020) does not define logic how to determine type of union,
only how to validate it.

Classes present in src/main/java are intended for user to customize
behaviour which type sould be used for serialization.

There is opened enhancement issue for MDSAL-49 which will not require
users anymore to customize class.

In meantime you could fill out implementation of these classes,
or use already generated sources for ietf-inet-types and ietf-netconf-monitoring
from YANGTools and controller project.

Marking this as duplicate of MDSAL-49 since behaviour described by you is by design and will be removed by MDSAL-49.

Tony, thank you for your reply! This is quite interesting design.

I noticed that in src/main/java, those generated classes are all Builder classes for unions, you also mentioned this. Did you mean that I need to implement getDefaultInstance method?

And for most projects, the classes will be generated under src/main/yang-gen-sal, and src/main/java is also a source folder, so you won't expect compilation error, right?

Yeah, that is true - you need to implement this method.

This pattern - which generates stubs in src/main/java is pretty common across code generators for code, which needs to be implemented, but code generator does not
have enough inteligence to provide implementation.

This code needs also to be checked in.

For models in question (ietf-inet-types@2010-09-24.yang and ietf-netconf-monitoring@2010-10-04.yang) I suggest using ones already present in nexus,
since they already have these builders implemented by YANGTools and COntroller developers.

Thanks a lot, the jars implemented by YANGTools and COntroller developers will be a good reference for me.

I found ietf-inet-types and ietf-netconf-monitoring artifacts in Nexus, they are under <groupId>org.opendaylight.controller</groupId>. However, in yangtools repo, ietf-inet-types are under <groupId>org.opendaylight.yangtools.model</groupId>, do you know why there is difference? Which one shall I use?

I didn't find the module for ietf-netconf-monitoring in yangtools repo, is the module stored somewhere else? Please let me know, thank you!

Looking forward to your reply! Thanks!

ietf-inet-types is org.opendaylight.yangtools.model because it is protocol agnostic .

ietf-netconf-monitoring is org.opendaylight.controller is in controller (netconf subsystem) because it is directly related to netconf.

You could use both (ietf-netconf-monitoring uses ietf-inet-types from yangtools).