The directory structure for an object-oriented ABL application is in a Progress Developer Studio for OpenEdge project.

A particular class is in a directory which is nested several levels under the project directory. The first directory under the project directory is not the leading field in the class definition as the developer intended it to be, due to an oversight while refactoring code. In spite of this, the class compiles.

No error messages are seen in Problems view.

No error decorations are seen in Project Explorer.

A .r file is generated.

Other files in the project that reference the above class by its fully qualified package name raise error (5638) at compile time as though the class had not compiled.

Directory/file hierarchy is similar to the following:
 
Class Util2a is defined as follows in Util2a.cls:
 
Class Caller.cls defines an instance of Util2a as:
 
If the class definition for Util2a is modified as follows, all compilation errors in the project are resolved:
 
Project MyProjectDirectory is configured with the default PDS propath:
 

This is expected behavior.

1. Util2a.cls compiles correctly no matter how its package name is defined. This is because it is not necessary for the compiler to know how other classes will reference Util2a.cls in order to compile it. Other classes might reference Util2a.cls relative to MyProjectDirectory, relative to MyUtilityDirectory, or relative to MyUtilityDirectory/MyType2Utils. The compiler cannot tell which it will be, so it does not enforce any starting point for the package name as long as the starting point is somewhere along the current directory hierarchy, and as long as the package name corresponds with the directory hierarchy from that starting point all the way down to the class itself.

2. Classes and procedures that reference Util2a.cls must reference it relative to the Propath. Since the Propath only includes the project directory (@{ROOT}), the OpenEdge work directory (@{WORK}), and the standard directories and procedure libraries, this means that all classes and procedures in the project that reference Util2a must qualify it with MyUtilityDirectory.MyType2Utils (either directly or through a USING statement).

3. If the other classes and procedures are going to reference Util2a.cls as MyUtilityDirectory.MyType2Utils.Util2a, the class must be defined as MyUtilityDirectory.MyType2Utils.Util2a in Util2a.cls. The compiler cannot enforce this when compiling Util2a.cls; it can only enforce it when it compiles classes that reference Util2a.

Design the application's directory hierarchy first, set the project Propath accordingly, and then define classes that are correctly qualified based on a directory in the Propath.

In the example above, Util2a.cls should contain the following class definition statement:
 

References to Other Documentation:

OpenEdge Development: Object-oriented Programming