RO : Java. RODL2Code Namespacing inconsistent

We use the command line tools to generate Java client files from RODL files. In the past that has just been from one large RODL file which worked fine. Now I need to split the files into separate RODL files. The namespacing is putting up a fight though. The namespace specified in the RODL file is used inconsistently by RODL2Code. I would prefer to specify the namespace in the RODL, not the command line but it seems this is not possible.
The two RODL files in the screenshot below have their own name space defined.

When code is generated using a namespace on the command line the output is :

The import statement is wrong. No files were generated with that namespace.

If I generate the files without specifying the namespace on the command line, the output is :


So the overall questions.

1.) If not specifying the namespace on the command line, why doesn’t the generated file use the namespace stored in the RODL? It does for the import statements but not the package name.

2.) If a namespace is used on the command line, would it be better to not output the import statement? it is unlikely to be correct unless the user specifies the same namespace in all the RODL files and at the command line for each RODL file.


Thanks, logged as bugs://82847


Sorry for the belated answer.

We have fixed the issue with the RODL-defined namespace not used when an override is not defined in the command line.

In your case the referenced RODL doesn’t have the “Generate Code for the definitions in this RODL file” set. So CodeGen assumes that code for that referenced RODL will be generated in a separate file, so it needs to reference it somehow. Unfortunately at the same time CodeGen has no information regarding which namespace will be used to generate files for that additional RODL. So it assumes that the code will be generated using the namespace defined in that RODL and adds this namespace via the import statement.
In the case when user generates code for the referenced RODLes using a namespace different than the one defined in these RODLes, then it is up ytoi that user to ensure that the import statements will use the correct namespace


That’s great thanks. The fix for 1.) will sort all of this out because I can stop specifying the namespace on the command line.

I’ll check it out with the next release.