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-992 yangtools <p>If the yang submodule is importing external module and using its extension, the build is failing with exception (see bellow). If the import of external module is added to the parent module of the submodule, it works.</p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java"> [ERROR] yang-to-sources: Unable to generate sources with org.opendaylight.mdsal.binding.maven.api.gen.plugin.CodeGeneratorImpl generator java.lang.IllegalArgumentException: Failed to find prefix <span class="code-keyword">for</span> statement (urn:example:module2?revision=2019-05-17)ext1     at com.google.common.base.Preconditions.checkArgument (Preconditions.java:210)     at org.opendaylight.yangtools.yang.model.export.ExportUtils.statementPrefix (ExportUtils.java:62)     at org.opendaylight.yangtools.yang.model.export.YangTextSnippetIterator.pushStatement (YangTextSnippetIterator.java:199)     at org.opendaylight.yangtools.yang.model.export.YangTextSnippetIterator.computeNext (YangTextSnippetIterator.java:160)     at org.opendaylight.yangtools.yang.model.export.YangTextSnippetIterator.computeNext (YangTextSnippetIterator.java:42)     at com.google.common.collect.AbstractIterator.tryToComputeNext (AbstractIterator.java:140)     at com.google.common.collect.AbstractIterator.hasNext (AbstractIterator.java:135)     at org.opendaylight.mdsal.binding.java.api.generator.BaseTemplate.appendYangSnippet (BaseTemplate.java:424)     at org.opendaylight.mdsal.binding.java.api.generator.BaseTemplate.appendSnippet (BaseTemplate.java:391)     at org.opendaylight.mdsal.binding.java.api.generator.BaseTemplate.formatDataForJavaDoc (BaseTemplate.java:342)     at org.opendaylight.mdsal.binding.java.api.generator.InterfaceTemplate.body (InterfaceTemplate.java:73)     at org.opendaylight.mdsal.binding.java.api.generator.BaseTemplate.generate (BaseTemplate.java:88)     at org.opendaylight.mdsal.binding.java.api.generator.InterfaceGenerator.generate (InterfaceGenerator.java:34)     at org.opendaylight.mdsal.binding.java.api.generator.GeneratorJavaFile$GeneratorStringSupplier.get (GeneratorJavaFile.java:54)     at org.opendaylight.mdsal.binding.java.api.generator.GeneratorJavaFile$GeneratorStringSupplier.get (GeneratorJavaFile.java:43)     at org.opendaylight.mdsal.binding.maven.api.gen.plugin.CodeGeneratorImpl.generateSources (CodeGeneratorImpl.java:113)     at org.opendaylight.yangtools.yang2sources.plugin.YangToSourcesProcessor.generateSourcesWithOneGenerator (YangToSourcesProcessor.java:380)     at org.opendaylight.yangtools.yang2sources.plugin.YangToSourcesProcessor.generateSources (YangToSourcesProcessor.java:330)     at org.opendaylight.yangtools.yang2sources.plugin.YangToSourcesProcessor.conditionalExecute (YangToSourcesProcessor.java:157)     at org.opendaylight.yangtools.yang2sources.plugin.YangToSourcesMojo.execute (YangToSourcesMojo.java:124)     at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (DefaultBuildPluginManager.java:137)     at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:210)     at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:156)     at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:148)     at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117)     at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:81)     at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:56)     at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:128)     at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)     at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)     at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)     at org.apache.maven.cli.MavenCli.execute (MavenCli.java:956)     at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288)     at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)     at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)     at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:62)     at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)     at java.lang.reflect.Method.invoke (Method.java:498)     at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:289)     at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:229)     at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:415)     at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:356) [ERROR] yang-to-sources: One or more code generators failed, including failed list(generatorClass=exception) {org.opendaylight.mdsal.binding.maven.api.gen.plugin.CodeGeneratorImpl=java.lang.IllegalArgumentException} </pre> </div></div> YANGTOOLS-992

Submodule importing extension from different file failed

Bug Medium Resolved Done Robert Varga Anna Bencúrová Fri, 17 May 2019 09:44:40 +0000 Fri, 31 Jan 2020 12:04:00 +0000 Fri, 31 Jan 2020 12:04:00 +0000 2.0.16 5.0.0 3.0.10 4.0.7 0 2 <p>The problem is the grouping in here and the fact it is inlined in the base module (see AbstractEffectiveModule) – MD-SAL codegen knows nothing about submodules, nor should it. The prefix resolver relies on the effective import map known to the module and it does not traverse additional imports (as inlined). So we have an effective statement, whose declared counterpart lives in a different module and there is not enough information retained, as the import statements are not inlined.</p> <p>This only affects root module statements, hence it is possible to get around this by special-casing the case when we have submodules and match them up on identity. Ugly, but it should work.</p> <p>DeclaredStatementFormatter is constructing the prefix map, and I think it should be able to discern when a statement is coming from submodule – but that is probably a costly operation.</p> <p>The problem is also that the cross-relationship passed from MD-SAL is not limited to top-level nodes – it can be any nested node. I think the fix here should be:</p> <ul> <li>index submodule imports (either in export or in actual EffectiveSubmoduleStatement)</li> <li>fall back to checking per-module imports for a prefix match if we fail to find a prefix – this needs then be re-assured by finding the statement</li> <li>that is really saying that there is a bloom filter for prefixes – where conflicts are not likely, but can happen</li> <li>costly operation is validation, which involves a linear search of all of submodule's substatements (comparing on identity), so that needs to be avoided</li> </ul> <p>The resulting lookup class is probably a good candidate for yang-model-util, but it cannot really be tested there, so keeping it in yang-model-export is good enough.</p> <p> </p> <p>Another option is to include prefix mapping at each effective statement – but that is not really helpful, as we are working on declared statements.</p> Development Rank 0|i03nvb: