https://jira.opendaylight.org This file is an XML representation of an issue en-us 8.20.10 820010 22-06-2022 https://jira.opendaylight.org/browse/YANGTOOLS-410 yangtools <p>Hi</p> <p>I want to generate java classes from ietf-inet-types@2010-09-24.yang and ietf-netconf-monitoring@2010-10-04.yang, I defined the generation folder to be target/test/src, but there are several classes generated under src/main/java, as attached picture. It causes compilation error, do you know why? Thank you!</p> <p>Yang files are also attached.</p> <p>Operating System: All<br/> Platform: All</p> YANGTOOLS-410

Classes were not generated under destination folder, cause compilation error of generated classes

Bug Resolved Duplicate Unassigned Minna Hu Sat, 14 Feb 2015 00:52:40 +0000 Sun, 10 Apr 2022 18:35:28 +0000 Wed, 18 Feb 2015 08:02:27 +0000 0 2 <p>Attachment ietf-netconf-monitoring@2010-10-04.yang has been added with description: ietf-netconf-monitoring</p> <p>Attachment ietf-inet-types@2010-09-24.yang has been added with description: ietf-inet-type</p> <p>Attachment bug.PNG has been added with description: classes generated in wrong place</p> <p>YANG (RFC6020) does not define logic how to determine type of union,<br/> only how to validate it.</p> <p>Classes present in src/main/java are intended for user to customize<br/> behaviour which type sould be used for serialization.</p> <p>There is opened enhancement issue for <a href="https://jira.opendaylight.org/browse/MDSAL-49" title="Do not generate Builders for Union types" class="issue-link" data-issue-key="MDSAL-49"><del>MDSAL-49</del></a> which will not require<br/> users anymore to customize class.</p> <p>In meantime you could fill out implementation of these classes,<br/> or use already generated sources for ietf-inet-types and ietf-netconf-monitoring<br/> from YANGTools and controller project.</p> <p>Marking this as duplicate of <a href="https://jira.opendaylight.org/browse/MDSAL-49" title="Do not generate Builders for Union types" class="issue-link" data-issue-key="MDSAL-49"><del>MDSAL-49</del></a> since behaviour described by you is by design and will be removed by <a href="https://jira.opendaylight.org/browse/MDSAL-49" title="Do not generate Builders for Union types" class="issue-link" data-issue-key="MDSAL-49"><del>MDSAL-49</del></a>.</p> <p>Tony, thank you for your reply! This is quite interesting design.</p> <p>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?</p> <p>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?</p> <p>Yeah, that is true - you need to implement this method.</p> <p>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 <br/> have enough inteligence to provide implementation.</p> <p>This code needs also to be checked in.</p> <p>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,<br/> since they already have these builders implemented by YANGTools and COntroller developers.</p> <p>Thanks a lot, the jars implemented by YANGTools and COntroller developers will be a good reference for me.</p> <p>I found ietf-inet-types and ietf-netconf-monitoring artifacts in Nexus, they are under &lt;groupId&gt;org.opendaylight.controller&lt;/groupId&gt;. However, in yangtools repo, ietf-inet-types are under &lt;groupId&gt;org.opendaylight.yangtools.model&lt;/groupId&gt;, do you know why there is difference? Which one shall I use?</p> <p>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!</p> <p>Looking forward to your reply! Thanks!</p> <p>ietf-inet-types is org.opendaylight.yangtools.model because it is protocol agnostic .</p> <p>ietf-netconf-monitoring is org.opendaylight.controller is in controller (netconf subsystem) because it is directly related to netconf.</p> <p>You could use both (ietf-netconf-monitoring uses ietf-inet-types from yangtools).</p> Duplicate MDSAL-49 Development External issue ID 2720 External issue URL Rank 0|i0271z: