Jesktop applications ship in jars. The jar must contain a manifest that Jesktop can pick up on so that it know's what's inside the jar. Jesktop's manifest is placed in a directory called JESKTOP-INF inside the jar. The file name of the manifest is applications.xml and it is in XML format.

This xml file contains details of the application that may be included in the jar. Here is an example:

<?xml version="1.0"?>
<applications>
  <application single-instance="true">
    <display-name>Frimble Demo2</display-name>
    <launchable-target-name>Demos/FrimbleDemo2</launchable-target-name>
    <class>org.jesktop.frimble.demo2.FrimbleDemo2</class>
  </application>
</applications>
      

That this says is that there is one application in the jar. It's name for the purposes of lookup is Demos/FrimbleDemo2, it has a certain class for launching and that Jesktop should ponly allow a single instance to run at any one time.

This example details four other concepts.

1. Muliple apps in one jar - the application element is repeating.
2. Default applications - of use when an application is not being installed, merely run in situ inside it's jar.
3. Icons to represent apps - used when listing the app on the start menu or in a file-system view.
4. Application specific config files - the config for the app in question is specified elsewhere.

The example:

<?xml version="1.0"?>
<applications>
	<default-application target-name="Tools/Clock"
	  icon32="net/jesktop/apps/clock/Clock.gif"
	  icon16="net/jesktop/apps/clock/ClockSmall.gif"/>
	<application>
		<display-name>Clock</display-name>
		<launchable-target-name>Tools/Clock</launchable-target-name>
		<class>org.jesktop.apps.clock.Clock</class>
	</application>
	<application>
		<display-name>Directory Explorer</display-name>
		<launchable-target-name>Tools/DirectoryExplorer</launchable-target-name>
		<class>org.jesktop.windowmanagers.DirectoryExplorer</class>
	</application>
	<application>
		<display-name>Text Viewer</display-name>
		<launchable-target-name>Tools/TextViewer</launchable-target-name>
		<class>org.jesktop.apps.notepad.TextViewer</class>
	</application>
	<application>
		<display-name>Image Viewer</display-name>
		<launchable-target-name>Tools/ImageViewer</launchable-target-name>
		<class>org.jesktop.apps.imageviewer.ImageViewer</class>
		<application-config-file>net/jesktop/apps/imageviewer/ImageViewer.xml</application-config-file>
	</application>
	<application>
		<display-name>Drag Monitor</display-name>
		<launchable-target-name>Tools/Misc/DragMonitor</launchable-target-name>
		<class>org.jesktop.apps.misc.DragMonitor</class>
	</application>
</applications>
      

The application specific file for Imageviewer. The file name is net/jesktop/apps/imageviewer/ImageViewer.xml:

<?xml version="1.0"?>
<application>
  <icons icon32="net/jesktop/apps/imageviewer/ImageViewer32.gif"
    icon16="net/jesktop/apps/imageviewer/ImageViewer16.gif" />
</application>
      

Each jar that contains application may also contain other jars containing classes or resources that must be mounted in the classpath during execution. The following snippet illustrates Sun's XML parser and how an manifests may specify them as contained within the distribution. They follow the applications element in the applications.xml manifest.

<additional-jars>
  <jar where="contained">lib/jaxp.jar</jar>
  <jar where="contained">lib/parser.jar</jar>
</additional-jars>
      

This additional jar element may also indicate jars that are not contained within the distribution jar. The following shows this in use:

<additional-jars>
  <jar where="remote">http://somewhere.com/some/thing.jar</jar>
</additional-jars>
      

There are a number of rules to the use of this manifest.

1. Targets are launchable. Each application entry is a separate launchable target. Multiple apps may share tha same code base and will be loaded via the same classloader so must be able to co-exist with ench other in one VM sharing static space.
2. Targets are launchable multiple times. Unless the single-instance="true" attrible has been specified the target may be launched multiple times. A classloading issue again in that static must be used carefully.
3. JComponent or JFrimble devived class The class that Jesktop instantiates must be a subclass of JComponent or JFrimble. JFrame is not allowed on this class. Use one of the alternative Frimble solutions instead.

If you want to have an application that is dual mode in that it can run standalone as well as inside Jesktop, you'll want to have a META-INF/manifest.mf file that specifies the executable nature of the jar. This normal Java feature is completely supported.