[MDSAL-1] Binding Specification: Grouping, data, typedef and identity namespaces collide Created: 06/Nov/13  Updated: 09/Mar/18  Resolved: 10/Mar/17

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

Type: Improvement
Reporter: Robert Varga Assignee: Jakub Toth
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All

Issue Links:
Blocks
is blocked by MDSAL-40 Milestone: Implement Binding Specific... Resolved
Duplicate
is duplicated by MDSAL-6 Classes should be generated for typed... Resolved
is duplicated by MDSAL-179 Java binding v1 NPE: generateTypesFro... Resolved
is duplicated by MDSAL-207 grouping and leaf Can't have the same... Resolved
is duplicated by YANGTOOLS-405 Compilation error: grouping address-f... Resolved
is duplicated by YANGTOOLS-406 Compilation error: duplicate name for... Resolved

 Description   

Simple yang of:

grouping foo-input {
leaf whatever

{ type boolean; }

}

rpc foo {
input

{ uses foo-input; }


}

results in a class in the form of

'interface FooInput extends FooInput'

which fails to compile.

 Comments   
Comment by Robert Varga [ 21/Jan/14 ]

This will be addressed in next version of binding specification.

Comment by Robert Varga [ 31/Jul/14 ]

There are two possible options how to address this:

  • add an implicit prefix/suffix to all generated interfaces, which will say what sort of object it is (Grouping, DataContainer, etc.)
  • split the top-level package namespace into appropriate packages: org.opendaylight.yang.gen.v1. {rpc,grouping,data,notification,typedef}

    .<Namespace>...

Comment by Vratko Polak [ 06/Jul/16 ]

An example without grouping, in combination with case-insensitiveness of first letter:

typedef Foo

{ type string; }

container foo {
leaf bar

{ type Foo; }

}

Comment by Jakub Toth [ 09/Mar/17 ]

This should be fixed by https://git.opendaylight.org/gerrit/#/c/52007/27.

JUnit tests example:

  • Same class names in same package
    public void sameClassNamesSamePackageTest() { String normalizeIdentifier1 = NonJavaCharsConverter.normalizeClassIdentifier("org.example.same.package", "Foo"); String normalizeIdentifier2 = NonJavaCharsConverter.normalizeClassIdentifier("org.example.same.package", "fOo"); final String normalizeIdentifier3 = NonJavaCharsConverter.normalizeClassIdentifier("org.example.same.package", "foo"); assertEquals(normalizeIdentifier1, "Foo"); assertEquals(normalizeIdentifier2, "Foo1"); assertEquals(normalizeIdentifier3, "Foo2"); ... }
Comment by Jakub Toth [ 09/Mar/17 ]

(In reply to Robert Varga from comment #0)
> Simple yang of:
>
> grouping foo-input {
> leaf whatever

{ > type boolean; > }

> }
>
> rpc foo {
> input

{ > uses foo-input; > }


> }
>
> results in a class in the form of
>
> 'interface FooInput extends FooInput'
>
> which fails to compile.

So after use of NonJavaCharsConverter from https://git.opendaylight.org/gerrit/#/c/52007/27 this will never happen. The result will ->

'interface FooInput extends FooInput1' -> acceptable

Comment by Jakub Toth [ 09/Mar/17 ]

(In reply to Vratko Polák from comment #6)
> An example without grouping, in combination with case-insensitiveness of
> first letter:
>
> typedef Foo

{ > type string; > }

> container foo {
> leaf bar

{ > type Foo; > }

> }

The same here. After use of NonJavaCharsConverter will be result ->

'Foo and the next one Foo (or foo or fOo ..) will be Foo1'

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