Snapshots are Gold

Ever installed an application into an environment only to find it hacked to bits? The problem is generally gathering enough information on what has changed to point the finger at anyone. This is where snapshots come in. The basic component types have snapshot's built in, and assuming that the installPath is the actual install path for the component, then all works well. Otherwise there is the need to define your own snapshots and place them AFTER the everything is installed. Sample to come another time, but it's not rocket science.

The key thing is calling createSnapshot from an install block for system component types work off of the installPath. If your install does some other magic, like deploy a web application, then you will need to define a custom <snapshot> and use <addFile ... > to obtain a true snapshot of what has been installed.

Multiple References to a single Resource

The latest joy with using n1sps came up when I created two components that referenced the same resource.<br/>
<component name="a">
<componentreflist>
<component name="referenced" path="....">
</componentreflist>
</component>

<component name="b">
<componentreflist>
<component name="referenced" path="....">
</componentreflist>
</component>

From an OO perspective this is nice. You can introduce composition into your components, allowing commonality to be encapsulated within a separate component. The problem is that n1 sps doesn't appear to do any reference counting.

Extending the above sample to include uninstall blocks:

<component name="b">
<componentreflist>
<component name="referenced" path="....">
</componentreflist>
<uninstalllist>
<uninstallsteps returns="'false'" name="'default'" requirelocking="'true'">
<call blockname="'uninstall'">
<thiscomponent/>
</call>
<uninstall blockname="'default'">
<allnestedrefs/>
</uninstall>
</uninstallsteps>
</uninstalllist>
</component>

Now this is where it gets interesting. If we also have virtual host1 and virtual host2 having the same parent, installing component a and component b onto separate virtual hosts (but same physical server) means that one copy of the resource is installed. However, if you uninstall component a (for example), the referenced component will be completely uninstalled from the system! Running the install target for component a will result in n1sps believing that the referenced component is actually available, failing when you try to use the resource that is deployed!

Work arounds.
Don't uninstall nested references that are known to be shared. This is one way of knowing that it will be available, however it can make the system a mess when you do actually want to uninstall all components from the host.<br />Components a and b can reference a different version of the referenced component. I haven't tried this, but theoretically this should work as long as you pass in the required variables so that the parent (say component a) knows how to access the installed (referenced) component.
I haven't really looked at the uninstall component options. It may be possible to do reference counting, but from my quick glance I can't see that it does this easily.