Using the NetBeans Platform on the Server with Wicket on the Client

    <context-param>
        <param-name>netBeansHome</param-name>
        <param-value>{catalina.base}/webapps/blueOcean/WEB-INF/lib/blueocean</param-value>
    </context-param>
    <context-param>
        <param-name>netBeansUserDir</param-name>
        <param-value>{user.home}/.blueOcean/NetBeans</param-value>
    </context-param>

As explained earlier, braces are used as macro-expansion, their content will be replaced by the value of the related system property. Two things are worth mentioning here:

1. I'm supposing that I'll deploy the whole application as a single .war file. In this case, I will unpack the platform files under WEB-INF/lib/blueocean, that is pointed by the "netBeansHome" parameter. I'm relying on the fact that the property "catalina.base" points to the directory where Tomcat in installed.
2. If you're using a different Web Container (e.g. Glassfish), this part has to be modified. Also, I'm relying on the fact that the Web Container will actually expand a .war file on the disk (they are not required to do that, and could work in memory). The server needs to be properly configured for these requirements.

A properly packed, all-inclusive .war file can be created with this ant target:

    <target name="war" depends="build-zip">
       <zip destfile="dist/blueocean.war">
         <zipfileset src="WebApplicationWrapper/dist/WebApplicationWrapper.war" />
         <zipfileset src="dist/blueocean.zip" prefix="WEB-INF/lib"/>
       </zip>
    </target>

which relies upon the Platform "build-zip" target for packaging your application into a complete .zip file.

During the development, re-creating the whole .war and redeploying it could take too long. In this case, you can override the web.xml settings with these two system properties like these (the most practical way to do is to create a new instance of Tomcat inside the NetBeans IDE):

-Dnetbeans.home=/Users/fritz/Business/Tidalwave/Projects/blueOcean/trunk/src/lib/platform 
-Dnetbeans.build.dir=/Users/fritz/Business/Tidalwave/Projects/blueOcean/trunk/src/build/cluster

Both of them point to your working directory; the former to the base platform you're using for developing the application (in my case, a custom platform); the latter to the "build/cluster" directory, where NetBeans prepares the binary files for your application, laid out as a valid platform.

Now you just need to deploy the .war once, and then just compile your changes, and restart the .war inside Tomcat. Probably, working on it, it could be possible to play with the class loaders so you don't have to restart the .war every time. In any case, consider that the .war is very small, so it restarts almost immediately.