[MDSAL-332] Class name conflict if identity and grouping share the same name in one package Created: 05/Apr/18  Updated: 27/Jul/18  Resolved: 27/Jul/18

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

Type: Bug Priority: High
Reporter: Michal Cmarada Assignee: Robert Varga
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File test-error.txt    
Issue Links:
Relates
relates to MDSAL-350 Binding codegen should not tolerate d... Confirmed

 Description   

As an example ietf-routing model (https://tools.ietf.org/html/rfc8349#page-16) contains address-family as an Identity and also as grouping. This leads to two classes with the same name in one package to be generated. This then causes naming conflicts for these classes during build.

 Comments   
Comment by Jie Han [ 12/Apr/18 ]

This should properly be supported by introducing identifier namespace in binding v2 as well as 'action' statement.

Comment by Marek Gradzki [ 08/Jun/18 ]

Is it possible to fix it in binding v1?

Comment by Robert Varga [ 08/Jun/18 ]

It may be possible, but that requires some analysis. What is the error reported in Fluorine?

Comment by Marek Gradzki [ 13/Jun/18 ]

Michal: were you able to reproduce the issue using Fluorine?

Comment by Michal Cmarada [ 14/Jun/18 ]

Using Fluorine the model builds, it just fails in Oxygen.

I used these patches to test it:
Oxygen: https://git.opendaylight.org/gerrit/#/c/72983/
Fluorine: https://git.opendaylight.org/gerrit/#/c/72984/

error output from build in attachement

Comment by Robert Varga [ 18/Jun/18 ]

Right, but the fact it compiles is actually wrong, as we are ending up with overwritten files and completely wrong type hierarchy:

[WARNING] Naming conflict for type 'org.opendaylight.yang.gen.v1.urn.opendaylight.params.xml.ns.yang.test.module.rev180614.AddressFamily': file with same name already exists and will not be generated.
Comment by Robert Varga [ 18/Jun/18 ]

So yes, this is fixable, but it requires rather extensive work:

  • mdsal-binding-generator-impl needs to perform two-phase name assignment to detect the conflict
  • a conflict-free naming scheme for use when a conflict occurs needs to be designed and implemented
Comment by Robert Varga [ 26/Jul/18 ]

Conflicts will be resolved as follows:

  • identities get a $I suffix
  • groupings get a $G suffix
  • typedefs get a $T suffix

For now we will treat a conflict as an error path, recording what needs to be remapped and retrying the entire mapping attempt.

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