Page History

...

...

Nodes, Properties and in fact complete subtrees may be described in XML files
using the following skeleton structure:either the JCR SystemView format, or the format described below. In either case, the file must have the .xml extension.

<node>
		<!--
			optional on top level, defaults to XML file name without .xml extension
	       	required for child nodes
		-->
		<name>xyz</name>

		<!--
	   		optional, defaults to nt:unstructured
		-->
		<primaryNodeType>nt:file</primaryNodeType>

		<!--
		    optional mixin node type
		    may be repeated for multiple mixin node types
		-->
		<mixinNodeType>mix:versionable</mixinNodeType>
		<mixinNodeType>mix:lockable</mixinNodeType>

		<!--
			Optional properties for the node. Each <property> element defines
			a single property of the node. The element may be repeated.
		-->
		<property>
			<!--
				required property name
			-->
			<name>prop</name>

			<!--
				value of the property.
				For multi-value properties, the values are defined by multiple
				<value> elements nested inside a <values> element instead of a
				single <value> element
			-->
			<value>property value as string</value>

			<!--
				Optional type of the property value, defaults to String.
				This must be one of the property type strings defined in the
				JCR PropertyType interface.
			<type>String</type>
		</property>

		<!--
			Additional child nodes. May be further nested.
		-->
		<node>
		....
		</node>
	</node>

If you're including binary files (nt:file) in your content, you may store them anywhere, and reference them from your XML by using nt:file elements. Use the <nt:file> instead of a <node> where you want your file to appear in your repository content:

  <nt:file src="url/relative/to/this/xml/image.jpg" mimeType="image/jpeg" lastModified="2009-10-27'T'10:50:15+0100" />

You may leave out the lastModified attribute - if so, the file's last modified date as reported by the filesystem will be used.

Using a custom XML format

By writing an XSLT stylesheet file, you can use whatever XML format you prefer. The XML file references an XSLT stylesheet by using the xml-stylesheet processing instruction:

<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet href="my-transform.xsl" type="text/xsl"?> <!-- The path to my-transform.xsl is relative to this file -->

<your_custom_root_node>
   <your_custom_element>
   ...
   </your_custom_element>
...
</your_custom_root_node>

The my-transform.xsl file is then responsible for translating your format into one of the supported XML formats:

<xsl:stylesheet version="1.0" xmlns:jcr="http://www.jcp.org/jcr/1.0" xmlns:mix="http://www.jcp.org/jcr/mix/1.0" 
  xmlns:sv="http://www.jcp.org/jcr/sv/1.0" xmlns:sling="http://sling.apache.org/jcr/sling/1.0"
  xmlns:rep="internal" xmlns:nt="http://www.jcp.org/jcr/nt/1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

  <xsl:template match="your_custom_element">
    <node>
      ...
    </node>
  </xsl:template>
  ...
</xsl:stylesheet>

JSON Descriptor Files

Nodes, Properties and in fact complete subtrees may be described in JSON files using the following skeleton structure (see http://www.json.org or information on the syntax of JSON) :

...

By default, the sling-jcr-contentloader bundle tries to extract certain file types during content loading. These include json, xml, zip, and jar files. Therefore all available extractors are used for content processing. However if some files should be put into the repository unextracted, the ignoreImportProviders directive can be used with a comma separated list of extensions that should not be extracted, like ignoreImportProviders:=jar,zip.

Workspace Targetting

By default, initial content will be loaded into the default workspace. To override this, add a Sling-Initial-Content-Workspace bundle manifest header to specify the manifest. Note that all content from a bundle will be loaded into the same workspace.

Declared Node Type Registration

...