Component level sdd.xml file overview
For most installation scenarios, generation of the component level sdd.xml file is automated. However, there are still occasions where it might be necessary to create it manually. The component level sdd.xml file contains the information on how to install the artifacts of the component. It lists the extension points that need to be processed. The extension points ensure that the resources can be installed and configured on the server. Ant tasks complete the deployment and configuration work.
Sample sdd.xml file
<iudd:iudd
xmlns:iudd="http://www.ibm.com/xmlns/prod/autonomic/solutioninstall/IUDD"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:OSRT="http://www.ibm.com/xmlns/prod/autonomic/resourcemodel/OS/resourcetypes"
xmlns:OSAT="http://www.ibm.com/xmlns/prod/autonomic/resourcemodel/OS/artifacttypes"
xmlns:J2EERT="http://www.ibm.com/xmlns/prod/autonomic/resourcemodel/J2EE/resourcetypes"
xsi:schemaLocation="http://www.ibm.com/xmlns/prod/autonomic/solutioninstall/IUDD
../iudd/iudd.xsd"
schemaVersion="2.0.0" buildID="112220" buildDate="2006-01-19T12:00:00">
<packageIdentity contentType="Component">
<name>components/componentN</name>
<version>8.0.0.0</version>
<displayName key="d0001" default="components/componentN" />
<manufacturer>
<displayName key="AC_01" default="IBM" />
</manufacturer>
</packageIdentity>
<topology>
<resource type="OSRT:OperatingSystem" id="OS" />
</topology>
<content xsi:type="iudd:RootIUContent">
<rootIU id="components/componentN">
<variables>
<parameters>
<parameter name="installLocation"
defaultValue="/usr/dummy.offr.1" />
<parameter name="FunctionalArea" defaultValue="featurepackSI" />
</parameters>
</variables>
<SCU id="deploy-portlets-applySIFeaturePack" targetRef="OS">
<identity>
<name>Do Configuration Task</name>
<version>8.0.0.0</version>
<displayName key="keyInBundle"
default="Executes Configuration for this component" />
<description key="keyInBundle"
default="This section runs configuration for this component" />
</identity>
<unit>
<configArtifact type="ConfigEngine">
<parameters>
<parameter name="targetName" value="deploy-portlets-applySIFeaturePack" />
</parameters>
</configArtifact>
</unit>
</SCU>
<SCU id="remove-portlets-applySIFeaturePack" targetRef="OS">
<identity>
<name>Do Configuration Task</name>
<version>1.0.0.0</version>
<displayName key="keyInBundle"
default="Executes Configuration for this component" />
<description key="keyInBundle"
default="This section runs configuration for this component" />
</identity>
<unit>
<configArtifact type="ConfigEngine">
<parameters>
<parameter name="targetName" value="remove-portlets-applySIFeaturePack" />
</parameters>
</configArtifact>
</unit>
</SCU>
</rootIU>
</content>
</iudd:iudd>
See The component level sdd.xml file for information about editing the sdd.xml file.
Syntax information for component names
The syntax for naming the component is important. There are dependencies within the PAA file that determine part of the component name that is registered in the sdd.xml file. You are free to name your components as you like; however, the component names must be unique. The ConfigEngine and by extension Solution Installer impose a restriction that a component name not clash with an existing component in the ConfigEngine registry. This restriction is not limited to an assembly, but is registry wide. Therefore, if a component has the same name as an existing component, it is not automatically installed. If the user wants to install this new component, they can use the update-paa-components task. This task removes the existing version and installs the new component as part of the new assembly.
When you register the names in the sdd.xml files, you must adhere to the following syntax: components/componentName. This syntax is necessary for the Solution Installer to resolve the component name. It must contain the full path from the directory that contains the assembly level sdd.xml file, usually the root directory, to the component level sdd.xml file.
Looking at the PortalServer_root/doc/paa-samples/sample1.paa file, it contains one component in the components directory called 'Sample1'. Therefore, The component name would appear in the sdd.xml file as follows: components/Sample1. It is the full path relative to the directory that contains the assembly level sdd.xml file.
The Solution Installer follows the feature pack approach that is provided by the ConfigEngine to install the individual components. The advantage of this approach is that the ConfigEngine manages the installation order of the individual components. Using the feature pack approach ensures a distinction between portal core extension points and those points that are used to install the PAA content. This approach reduces the risk of a user accidentally removing portal core components when you run a remove extension point.
SCU
elements. The first one shows how to register the extension point
to deploy a portlet and the second one demonstrates how to remove the
portlets.<SCU id="deploy-portlets-applySIFeaturePack" targetRef="OS">
<identity>
<name>Do Configuration Task</name>
<version>1.0.0.0</version>
<displayName key="keyInBundle" default="Executes Configuration for this component" />
<description key="keyInBundle" default="This section runs configuration for this
component" />
</identity>
<unit>
<configArtifact type="ConfigEngine">
<parameters>
<parameter name="targetName" value="deploy-portlets-applySIFeaturePack" />
</parameters>
</configArtifact>
</unit>
<register a dependency on a previous component-->
<requirements>
<requirement name=" deploy-portlets-applySIFeaturePack">
<alternative name="dependentComponent"/>
</requirement>
</requirements>
</SCU>
The SCU
element example notifies the Solution
Installer about the task you want to run. The extension point in this case is called
deploy-portlets-applySIFeaturePack. It
deviates from the core extension points for portal by adding applySIFeaturePack’ to
the end of the extension point. With an uninstall task, ‘removeSIFeaturePack’ is
appended instead. It allows the Solution Installer to distinguish between
installation and uninstall tasks. Append these strings to the extension point names
to create a definite distinction between core extension points and those points
included for the Solution Installer to handle a PAA distribution. The Solution
Installer expects and runs only extension points that conform to this format.
To provide an implementation task for an extension point, read Installation tasks for information.