If the content root in the file system for your repository contains a large number of files, the FileSystemMonitorService might require a long time to identify which files and folders to load into the repository, and for the LoaderManager and ContentHandlers to convert the files and folders into repository items. You can reduce processing overhead by creating a Repository Loader manifest file that identifies in advance the files and folders to load.

For example, the following Repository Loader manifest file adds five files:

<manifest>
  <add>/main/Dynamo/RL/sample-data/user001.xml</add>
  <add>/main/Dynamo/RL/sample-data/user002.xml</add>
  <add>/main/Dynamo/RL/sample-data/user003.xml</add>
  <add>/main/Dynamo/RL/sample-data/user004.xml</add>
  <add>/main/Dynamo/RL/sample-data/user005.xml</add>
</manifest>

Elements in a Repository Loader manifest file are handled in order of appearance, so one element should not depend on a later element. For example, a content repository requires a folder hierarchy; so a content item should not precede the folder that contains it.

Document Type Definition

The Repository Loader manifest file is an XML file that conforms to the following DTD:

<!--
====================================================================
rl-manifest_1.0.dtd - document type for Repository Loader manifests
Version: $Id: //product/DAS/main/Java/atg/dtds/rl/rl-manifest_1.0.dtd#1 $
$Change: 286550 $
====================================================================
-->
<!-- A single manifest composed of any number of add, update, remove tags -->
<!ELEMENT manifest (add | update | remove)*>
<!ATTLIST manifest num-elements CDATA #IMPLIED>
<!ELEMENT add (#PCDATA)>
<!ATTLIST add type-mapping CDATA #IMPLIED>
<!ELEMENT update (#PCDATA)>
<!ATTLIST update type-mapping CDATA #IMPLIED>
<!ELEMENT remove (#PCDATA)>
<!ATTLIST remove type-mapping CDATA #IMPLIED>