The Framework Archive File Format is defined as a Java Archive file, with a special xml file called FrameworkArchiveManifest.xml at the top of the archive. The FrameworkArchiveManifest.xml must be an instance of this schema.
</xs:documentation>
</xs:annotation>
<xs:elementname="FrameworkArchiveManifest">
<xs:annotation>
<xs:documentationxml:lang="en">
This schema defines the Framework Archive Manifest.
Extra contents that are not part of any Package or Platform. These file paths are WORKSPACE relative. If a file exists in the workspace at this location, then the user should be asked whether to overwrite. When the user removes the far, these should be removed also, unless they have been modified (per md5sum).
This is the default installation location within the workspace. This also serves as the location within the far itself of the package root. The Contents of the pacakage will be found there. The user may choose some other location within the workspace to install the package, as long as it does not overlap a package that is already installed.
This list of platforms is relative to the package root of the package that they are contained in. If the package that these are bound to is intstalled in some directory other than the default, then these platforms should be stored relative to that.
The FarFilename is used to build up the Contents list. It has an md5sum attribute for keeping track of whether the file is changed after it is installed. The Md5sum can also be used to check the integrity of a far before it is installed into the workspace.
</xs:documentation>
</xs:annotation>
</xs:element>
<xs:elementname="GuidValue"type="GuidType">
<xs:annotation>
<xs:documentation>
The purpose of this element is to allow Guids to be assigned to or used by other elements in the schema.
</xs:documentation>
</xs:annotation>
</xs:element>
<xs:elementname="Contents">
<xs:annotation>
<xs:documentation>
This tag allows us to specify a tree of files all having a common root. All the files specified are relative to that common root.
1. A module m is said to depend upon a package p, iff there exists a tuple (PackageGuid, PackageVerion) in the set m->PackageDependencies for which p->Guid==PackageGuid, and if PackageVersion is not empty, then p->Version== PackageVersion.
2. A far f is said to depend on a far g, iff there is a module in a package in f that depends on a package in g.
</xs:documentation>
<xs:documentation>
3. A far f is said to depend on a package p, iff there is a module m contained in f that depends on p.
</xs:documentation>
<xs:documentation>
3.1 A platform q is said to depend on a package p, iff p, or some module m contained in p, is necessary to build q.
</xs:documentation>
<xs:documentation>
4. A far f may be installed into the workspace w, iff for each module m in f, m’s dependencies are met by the packages in w.
</xs:documentation>
<xs:documentation>
a. (If the dependencies are not met, then no part of far f will be installed. It is not legal to partially install a far into the workspace.)
</xs:documentation>
<xs:documentation>
5. A far f may be removed from the workspace w, iff for each module m in w, and for each package p in f, m does not depend on p.
</xs:documentation>
<xs:documentation>
a. (If there is some dependency on f, then no part of f may be uninstalled from w. It is not legal to partially uninstall a far from the workspace.)
</xs:documentation>
<xs:documentation>
6. When installing a far f into workspace w, for each package p in f, allow the user to install in p's default location, or choose a new location l (which must be unoccupied) within the workspace. Record this location l in the database. Each package p in f will be recorded in the database, associated with the GUID of f, as well as the actual install location l. (So we will know which far each package belongs to.)
</xs:documentation>
<xs:documentation>
7. When installing a far f into workspace w, if there exists a package p in w, and p is in f, then the user must be prompted to choose a location that does not collide with the location of p in workspace w. We will end up with two instances of p in w at two distinct locations.
</xs:documentation>
<xs:documentation>
8. A far f may replace a far g in the workspace w, iff for each module m contained in w, if m depends on a package p, and p is only contained in g, then there must exist a package q in f, such that m depends on q. The net effect is that g is removed and f is installed, in one operation. The normal rules for installing f still apply--the dependencies of the modules of f must be satisfied. After the replacement, it must be the case that all the modules dependencies in the workspace are satisfied. Note that it is possible to backrev a package in this way.
</xs:documentation>
<xs:documentation>
(If we find that the replace is not permitted, then the user may install f and keep g. Next, he could _port_ every module m in w that depends on g, to f and eventually remove g.)
</xs:documentation>
<xs:documentation>
9. A special case of the above rule is that a far f may be reinstalled into the workspace. (This would allow the user to get a fresh copy, or change the location in the workspace where one or more of the packages of f are installed.)
</xs:documentation>
<xs:documentation>
10. When a far f is removed from the workspace w, for each package p in f, we will remove p from w.
</xs:documentation>
<xs:documentation>
11. If a package p belongs to a far f, then it is not legal to remove p from the workspace w unless f is removed from w.
</xs:documentation>
<xs:documentation>
11.1 If a platform p belongs to a far f, then it is not legal to remove p from the workspace w unless f is removed from w.
12. A package p may be removed from the workspace, provided there does not exist a far f that contains p. (Newly created or cloned packages will not exist within a far, and thus may be removed from the workspace directly.)
13. When a far f is removed from the workspace, the we will remove all the files in f from the workspace tree. If a file has been modified from the original as installed from the far (per md5sum) then the user should be asked if he is "sure" he wants to remove it.
14. When a far is created, a GUID is generated and assigned to the far. If a far is created from the same components at a later time, it would have a different GUID.
16. When constructing a far f that contains at least one platform, then f may optionally be constructed such that for each platform q in f, every package p on which q depends should be included in f, unless p->RePackage==false. The far will have all the packages required, and may then be installed as a self-inflating executable that will create a brand new workspace on the developer's workstation.
