[MDSAL-327] Imports for nested generated classes do no work Created: 22/Mar/18  Updated: 02/May/18  Resolved: 02/May/18

Status: Resolved
Project: mdsal
Component/s: Binding codegen
Affects Version/s: None
Fix Version/s: Fluorine

Type: Improvement Priority: High
Reporter: Brady Johnson Assignee: Robert Varga
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Relates
relates to TSC-98 Binding V1 import tracking codegen ch... Resolved

 Description   

We have several YANG files in the SFC project that havent been touched in a while that whose generated Java files no longer compile in Fluorine, as can be seen here [0].
 
Here is an example of the compilation errors:
 

18:27:21 [ERROR] /w/workspace/sfc-maven-verify-fluorine-mvn33-openjdk8/sfc-renderers/sfc-ios-xe-renderer/src/main/yang-gen-sal/org/opendaylight/yang/gen/v1/urn/ios/rev160308/_native/mls/qos/Map.java:[8,1] org.opendaylight.yang.gen.v1.urn.ios.rev160308._native.mls.qos.Map is already defined in this compilation unit
18:27:21 [ERROR] /w/workspace/sfc-maven-verify-fluorine-mvn33-openjdk8/sfc-renderers/sfc-ios-xe-renderer/src/main/yang-gen-sal/org/opendaylight/yang/gen/v1/urn/ios/rev160308/_native/mls/qos/Map.java:[70,37] type org.opendaylight.yang.gen.v1.urn.ios.rev160308._native.mls.qos.Map does not take parameters*18:27:21* [ERROR] /w/workspace/sfc-maven-verify-fluorine-mvn33-openjdk8/sfc-renderers/sfc-ios-xe-renderer/src/main/yang-gen-sal/org/opendaylight/yang/gen/v1/urn/ios/rev160308/_native/mls/qos/Map.java:[71,37] type org.opendaylight.yang.gen.v1.urn.ios.rev160308._native.mls.qos.Map does not take parameters

 
Have there been changes to Yangtools that could have caused this??
 
[0] https://jenkins.opendaylight.org/releng/job/sfc-maven-verify-fluorine-mvn33-openjdk8/43/console



 Comments   
Comment by Robert Varga [ 22/Mar/18 ]

Map as a compilation unit, coming from 'container map', containing restricted leaf-defined types – hence it requests import of java.util.Map, which is output. This leads to confusion. The import should have been rejected and java.util.Map should be referenced via its FQCN.

Comment by Robert Varga [ 22/Mar/18 ]

The breakage was introduced by the fix of nested class imports, which is flushing out a bug.

Comment by Robert Varga [ 22/Mar/18 ]

Revert: https://git.opendaylight.org/gerrit/69863

 

Comment by Robert Varga [ 22/Mar/18 ]

The revert will fix the reported issue, repurposing this this issue to track re-implementation of the improvement.

Generated at Wed Feb 07 20:09:32 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.