PR# 13323 Incorrect .NET Namespace Generation

This is a breaking change. We have an ECF with the following target options:

	<option trace="false" profile="false" debug="false" warning="true" namespace="openehr">
	...
	<setting name="dotnet_naming_convention" value="false"/>
	<setting name="use_all_cluster_name_as_namespace" value="true"/>
	<setting name="use_cluster_name_as_namespace" value="true"/>

The ECF does not specify namespaces at the cluster level. Here is an example of two of the classes seen in the Clusters tool:

	- Clusters
	  - adl_parser
	    - syntax
	      - adl
	          ADL_ENGINE
	  - openehr
	    - am
	      - archetype
	          ARCHETYPE

In 5.7, these options produced the following fully-qualified class names:
	openehr.adl_parser.syntax.adl.ADL_ENGINE
	openehr.openehr.am.archetype.ARCHETYPE

But 6.0.6.9021 generates these:
	openehr.syntax.adl.ADL_ENGINE
	openehr.am.archetype.ARCHETYPE

http://eiffelsoftware.origo.ethz.ch/index.php/.NET_Namespace_Generation says:

"4. NN set to N: ...
         1. UCNN and URCNN set to True: N.root.A, N.root.d1.B and N.root.d2.C"

This describes the 5.7 behaviour. 6.0.6.9021 generates N.A, N.d1.B and N.d2.C, which is specified as the behaviour for UCNN false and URCNN true. In other words, UCNN is ignored if URCNN is true.

If this fix is accepted into 6.0, will the GPL download be updated too? The project where I noticed this is an open source project, so when we instruct people to download EiffelStudio, will they continue to get 6.0.6.9021 until 6.1 is released?

Peter, this issue has now been fixed in revision 69568. We are awaiting authorization to post the fix into our 6.0 release.

This is a problem. We actually have compiler regression test to test namespace generation which confirm this bug. I'm now working on a fix.

I've just successfully worked around this bug by specifying the namespace of each cluster. The workaround isn't too onerous, so I wouldn't call this critical.