Exported Package Overview
You can specify the classes exported in a package. Classes imported by a schema cannot be exported from that schema. You can selectively export properties, methods, and constants of a class. When a class is exported, some class and feature attributes may be overridden. For example, you can change the allowed lifetime and default persistence of a class, or change the access of a public property to read-only.
You can specify the application that is to be instantiated when a package is opened so that package-specific initialization and finalization logic is performed.
The classes exported in a package effectively define a set of interfaces to the package schema. The exported classes should be self-contained in the branch of the schema that defines the package (although the implementation of those classes may rely on other inherited or imported classes).
Packages can export public classes inherited from superschemas so that you can divide the implementation of a package or packages across multiple schemas and provide a lowest-level subschema from which all packages are exported. Importers of the package or packages need be aware of only one schema (the lowest-level schema that exports all packages), rather than having to imported packages from several implementation schemas.
As you can export classes inherited from superschemas, you must consider subschema copy classes. Consider the following schema and class hierarchy.
SchemaAClassA provides method m1. ClassB provides method m2. SchemaB (subschema of SchemaA)
ClassB provides method m3.
In this example, SchemaA::ClassA and SchemaA::ClassB are root classes, as they are the top-level definition of those classes. SchemaB::ClassA and SchemaB::ClassB are subschema copy classes, as they are definitions below the top-level definitions. Method m3 is a subschema copy method, as it is a method defined on a subschema copy class.
If ClassB is to be exported in a package, the methods that are available for export depend on whether it is the root class being exported or the subschema copy class. If SchemaA::ClassB is exported, method m2 is available for export. If SchemaB::ClassB is exported, methods m2 and m3 are available. As class names must be unique within a package, a single package cannot export both a root class and subschema copies of that root class. If SchemaA::ClassB were exported in a package and it later became necessary to export method m3, SchemaA::ClassB would need to be removed from the package and SchemaB::ClassB added.
In the above example, method m1 cannot be exported on ClassB. To export method m1, ClassA must be exported or method m1 must be reimplemented on ClassB (possibly performing only an inheritMethod call).
These issues do not exist when exporting properties, as properties can be defined only on root classes.
You cannot export a RootSchema subschema copy class. Exporting subclasses of
For details about exporting a package, see "Exporting a Package Using the Export Package Definition Wizard" or "Browsing and Maintaining an Exported Package", later in this chapter.
