PR# 14809 ECF <root>

Problem Report Summary
Submitter: ericbe
Category: Other
Priority: Medium
Date: 2008/09/21
Class: Bug
Severity: Serious
Number: 14809
Release: 6.3.7.4554
Confidential: No
Status: Suspended
Responsible: ted_eiffel
Environment: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; InfoPath.1; .NET CLR 3.0.04506.648)
Synopsis: ECF <root>

Description
In:

   http://www.eiffel.com/developers/xml/configuration-1-4-0.xsd

it is said that the attribute "class" of element "root" is required, but in base.ecf for example we have:

   <root all_classes="true"/>

No attribute "class"! I think that there is a deficiency in the way root is specified in the schema. I think that it should be a choice between cluster/class/feature where "class" is required on one hand, and all_classes on the other hand.

Also, we can see that <root> appears in a sequence, but there is no indication of what should happen if several <root> elements are specified in this sequence. EiffelStudio seems to arbitrarily choose the last specified one, without reporting any warning.
To Reproduce

										
Problem Report Interactions
From:manus_eiffel    Date:2008/10/22    Download   
I'm not sure to understand what you mean. Are you talking specifically about the testing tool or in general? For the testing tool, it is equivalent to having a different root than the one specified by the user but because the compiler knows about multiple roots, it does not have to pretend that the root specified by the user is not actually its root class. And also if it was a class, it also relies on all the validity rules that a root class should have and it will also become editable, .... So having this completely hidden and not creating a fake root class seems much better overall. And if the user wants some freedom, he can always get it by modifying its root class, but I think this will be very rare.

From:ericbe    Date:2008/10/22    Download   
I'm sorry, but I still don't see the advantage (apart from not having to write an extra class) compared to having an extra class that would call the root classes depending on the arguments or environment variables.

From:manus_eiffel    Date:2008/10/22    Download   
The idea is that the testing tool reuse the same binary. So we could introduce the notion of `metaroot' so to speak but because this has been requested in the past, we decided to allow more than one root in a project but postponed the UI integration of that to 6.4.

From:ericbe    Date:2008/10/22    Download   
So is it just about preventing people from having to write an extra class that would call the root classes depending on the arguments or environment variables? If it's only used by the test tool, why can't it do that by itself without introducing the notion of multiple roots?

From:arnofiva    Date:2008/10/22    Download   
This functionality is only used by the testing tool so far and currently it is not possible to define more than one root through the ecf file. However the plan is to add UI and configuration support for multiple roots in 6.4.
The idea is that one can specify multiple roots and choose which one to execute when launching the application. Currently this is done by a specific command line argument which is hidden from arguments in the Eiffel application. Another possibility would be a special environment variable.

From:ericbe    Date:2008/10/21    Download   
I already heard about multiple roots, but I have no idea what it means. Do you mean that you can compile a project with several roots at one? Can you explain what multiple roots are?

From:ted_eiffel    Date:2008/10/20    Status: Suspended    Download   
I change this to be suspended. A proper fix will be done in 6.4 when we will support multiple roots for the testing tool.

Now the schema only allow one root which is correct (Note that according to W3C, default value of maxOccurs is 1). However, EiffelStudio should report when there are multiple ones. But for now, again because in 6.4 we will support multiple roots, we decide to leave it as it is.

Yes, cluster, class, feature and all_classes attributes of root element are not well done in this way. Instead, we should use elements instead of attributes to describe constrains among these options. Because XML schema does not support choice  between attributes.