[MDSAL-75] CodeGenerator unable to generate class for grouping Created: 12/Mar/15  Updated: 09/Mar/18  Resolved: 10/Mar/17

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

Type: Bug
Reporter: Ladislav Borak Assignee: Unassigned
Resolution: Won't Do Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Windows
Platform: PC

Issue Links:
Blocks
is blocked by MDSAL-40 Milestone: Implement Binding Specific... Resolved
External issue ID: 2822
Priority: Normal

 Description   

Unable to generate java class file, for yang which contains these groupings:

grouping linkstate {
leaf distinguisher

{ type route-distinguisher; }

}

grouping link-state {
leaf local-ipv4-router-id

{ type ipv4-router-identifier; }

}

In console output:

[WARNING] Naming conflict for type 'org.opendaylight.yang.gen.v1.urn.opendaylight.params.xml.ns.yang.bgp.linkstate.rev150210.Linkstate': file with same name already exists and will not be generated.

This problem occurs in Windows environment, in linux all classes were generated properly.

 Comments   
Comment by Robert Varga [ 01/Jun/15 ]

What filesystem was this on? It sounds like a case-sensitivity issue. For obvious reasons we do not supporte case-insensitive filesystems.

Comment by Ladislav Borak [ 01/Jun/15 ]

It was tested on NTFS file system.

Comment by Colin Dixon [ 25/Sep/15 ]

Is limiting ourselves to case-sensitive filesystems a good idea? It seems like something that's likely to bite us (or more realistically a customer) at some point that could be avoided.

Comment by Robert Varga [ 27/Sep/15 ]

The java compiler insists on public compilation units containing a matching class declaration: http://www.javaworld.com/article/2073236/java---duplicate-class--and-mismatched-file-name-error.html.

The Binding Spec is very explicit as to when camel-casing occurs, e.g. 'container foo-bar' and 'container foobar' generate 'FooBar' and 'Foobar'.

Those two classes are not the same class in Java. If you throw in a case-insensitive filesystem, that means that two classes (FooBar and Foobar) which differ only in capitalization would map themselves to the same file – hence kaboom.

Solving this would mean a much more involved and user-unfriendly name mapping rules, so no, I would say not supporting case-insensitive filesystems is a very reasonable trade-off.

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