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/MDSAL-531 mdsal <p>the following two modules:</p> <p> </p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>module a { yang-version 1.1; namespace "a"; prefix a; import b { prefix b;} grouping foo { container bar { leaf foo { type string; } uses software-operation-state; } grouping software-operation-state { leaf bar2 { type empty; } uses next-operation-group; } grouping next-operation-group { list next-operation { key order; config false; leaf order { description "A logical sequence number of operations to be done."; type uint8; } leaf operation-type { description "Type of software action launched on the device."; type string; } leaf software-name { description "Name of the software on which the operation was performed. For download operations, the leaf only records the software name and not the complete URL."; type string; } } // list next-operation } } augment "/b:fooo" { uses a:foo; } } </pre> </div></div> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>module b { yang-version 1.1; namespace "b"; prefix b; container fooo { leaf baar { type empty; } } }</pre> </div></div> <p>results in AbstractTypeGenerator.addImplementedInterfaceFromUses() failure:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>[ERROR] yang-to-sources: Unable to generate sources with org.opendaylight.mdsal.binding.maven.api.gen.plugin.CodeGeneratorImpl generator java.lang.IllegalStateException: Grouping AbsoluteSchemaPath{path=[(a)foo, (a)next-operation-group]}is not resolved for SoftwareOperationState at org.opendaylight.mdsal.binding.generator.impl.AbstractTypeGenerator.addImplementedInterfaceFromUses (AbstractTypeGenerator.java:1887) at org.opendaylight.mdsal.binding.generator.impl.AbstractTypeGenerator.addDefaultInterfaceDefinition (AbstractTypeGenerator.java:1625) at org.opendaylight.mdsal.binding.generator.impl.AbstractTypeGenerator.addDefaultInterfaceDefinition (AbstractTypeGenerator.java:1593) at org.opendaylight.mdsal.binding.generator.impl.AbstractTypeGenerator.addDefaultInterfaceDefinition (AbstractTypeGenerator.java:1587) at org.opendaylight.mdsal.binding.generator.impl.AbstractTypeGenerator.groupingsToGenTypes (AbstractTypeGenerator.java:700) at org.opendaylight.mdsal.binding.generator.impl.AbstractTypeGenerator.addDefaultInterfaceDefinition (AbstractTypeGenerator.java:1624) at org.opendaylight.mdsal.binding.generator.impl.AbstractTypeGenerator.addDefaultInterfaceDefinition (AbstractTypeGenerator.java:1593) at org.opendaylight.mdsal.binding.generator.impl.AbstractTypeGenerator.processDataSchemaNode (AbstractTypeGenerator.java:281) at org.opendaylight.mdsal.binding.generator.impl.AbstractTypeGenerator.containerToGenType (AbstractTypeGenerator.java:299) at org.opendaylight.mdsal.binding.generator.impl.AbstractTypeGenerator.addSchemaNodeToBuilderAsMethod (AbstractTypeGenerator.java:1055) at org.opendaylight.mdsal.binding.generator.impl.AbstractTypeGenerator.resolveDataSchemaNodes (AbstractTypeGenerator.java:1004) at org.opendaylight.mdsal.binding.generator.impl.AbstractTypeGenerator.moduleToGenTypes (AbstractTypeGenerator.java:239) at org.opendaylight.mdsal.binding.generator.impl.AbstractTypeGenerator.&lt;init&gt; (AbstractTypeGenerator.java:200) at org.opendaylight.mdsal.binding.generator.impl.CodegenTypeGenerator.&lt;init&gt; (CodegenTypeGenerator.java:32) at org.opendaylight.mdsal.binding.generator.impl.BindingGeneratorImpl.generateTypes (BindingGeneratorImpl.java:64) at org.opendaylight.mdsal.binding.maven.api.gen.plugin.CodeGeneratorImpl.generateSources (CodeGeneratorImpl.java:70) at org.opendaylight.yangtools.yang2sources.plugin.YangToSourcesProcessor.generateSourcesWithOneGenerator (YangToSourcesProcessor.java:383) at org.opendaylight.yangtools.yang2sources.plugin.YangToSourcesProcessor.generateSources (YangToSourcesProcessor.java:332) at org.opendaylight.yangtools.yang2sources.plugin.YangToSourcesProcessor.conditionalExecute (YangToSourcesProcessor.java:159) at org.opendaylight.yangtools.yang2sources.plugin.YangToSourcesMojo.execute (YangToSourcesMojo.java:127)</pre> </div></div> MDSAL-531

Unable to resolve grouping

Bug Medium Resolved Done Unassigned Miroslav Kovac Wed, 11 Mar 2020 09:41:16 +0000 Tue, 18 May 2021 07:26:54 +0000 Tue, 18 May 2021 07:26:54 +0000 6.0.0 Binding codegen 0 2 <p>weird thing is that if we are not augmenting and we do following changes in module a:</p> <p> </p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre> augment "/b:fooo" { uses a:foo; } changed to container fooo { uses a:foo; }</pre> </div></div> <p>So we do not need module b anymore. The generator does not have problem. And even more weird same goes if we keep augmentation but we augment the same container in same model. So again we do not need module b and the module a would change like this:</p> <p> </p> <p> </p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre> augment "/b:fooo" { uses a:foo; } changed to augment "/a:fooo" { uses a:foo; } container fooo { leaf foo_leaf { type empty; } }</pre> </div></div> <p> </p> <p>Version 6.0.0 is not affected as we do not need to resolve the path – we have the grouping readily available.</p> <p>Right, and the problem seems to come from GroupingDependencySort – it is failing to reorder a:foo's grouping according to their dependencies, generating them in the declaration order. This means next-operation-group is not processed yet and hence its type does not exist yet.</p> <p>So a workaround would be to reverse the order of definition of these two.</p> <p>The sorting problem boils down to the two groupings being instantiated, i.e. having paths of:</p> <p> </p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>AbsoluteSchemaPath{path=[(b)fooo, (a)software-operation-state]} AbsoluteSchemaPath{path=[(b)fooo, (a)next-operation-group]}</pre> </div></div> <p>and the uses statement is pointing to original grouping:</p> <p> </p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>UsesEffectiveStatementImpl[groupingPath=AbsoluteSchemaPath{path=[(a)foo, (a)next-operation-group]}]</pre> </div></div> <p>So we end up not realizing that there is a dependency, as the pointer is all wrong.</p> <p> </p> Development Rank 0|i03re7: