CODE_PACKAGE values must be valid Java identifiers.
Setting theCODE_PACKAGE option for a package recursively affects sub-packages and process, facade, entity and struct classes within the package.
Specifying aCODE_PACKAGE value within a package whose parent has specified aCODE_PACKAGE will override the value specified by the parent rather than append to it.
For example:
Package A contains package B
Package A specifiesCODE_PACKAGE = cp1
Package B specifiesCODE_PACKAGE = cp2
Then:
The effective code package of classes in package A is cp1
The effective code package of classes in package B is cp2 ( Not cp1.cp2).
ACODE_PACKAGE setting of . (dot) or $ is interpreted as blank. (This is because a literal blank is ignored by the generator and therefore cannot be used to override a non-blank setting.)
Multiple level code packages may be specified using a similar syntax to Java packages whereby each level is delimited by a dot. For example, the following code package setting represents three levels of Java packages:
CODE_PACKAGE = cp1.cp2.cp3
TheCODE_PACKAGE option allows multiple struct and process classes to have the same name, however only one instance of each facade class name may exist. Cúram clients currently cannot distinguish between multiple facade classes with the same name, regardless of theirCODE_PACKAGE setting.
The behavior of theCODE_PACKAGE option with entity classes is the same as that of process and struct classes in that the resulting generated interface and struct classes are produced in different packages. However, entity class names must still be unique throughout the application regardless of theCODE_PACKAGE option setting. This is due to the fact that all entities correspond to tables in the single underlying database.
Generated list wrapper structs (triggered by the existence of readmulti operations) are produced in the same code package as the structs that they wrap. Note that this will not necessarily be the same code package as the operation which caused their creation.