WYSIWYG Dreamz: Jayanth.Krupanidhi@Sun.COM

Java Web Start & JNLP

One of the most exciting features that Java offers is the ability to execute Swing-based applications that reside on a remote server from a client's system using Java Web Start (JWS). Java Network Launching Protocol (JNLP) is the underlying protocol that specifies how JWS applications are launched.

A JNLP file is an XML file that includes information such as the URL codebase of the source, general information about the application, the location of all the required JAR files & other resources and the main class that serves as the entry point for the application, etc.

JNLP in openInstaller

openInstaller 0.9.4 introduces basic JNLP support for creating single-click installers. A customizable JNLP template named product-installer.jnlp can be found in the openInstaller source under “sample_product/resources”. Individual product installers could copy this template to their product metadata location, customize it by making very minimal changes & then use it to create a WebStart-version of their product installer.

Here are the steps to create a WebStart-based installer for the sample product that comes with the openInstaller source:

1. Download and extract the latest openInstaller source onto your local filesystem.

2. Build the source as per the instructions.

3. Create a JAR file called resources.jar with the entire contents of the "build/proto/install/lib/resources" directory and place it under build/proto/install/lib/resources. After creating the resources.jar file should have a structure like this.
resources.jar
|_ dependency
|_ model
|_ org
|_ templates
|_ view

4. All the JAR files under “build/proto/install/lib” and its subdirectories need to be signed before they can used by Java Web Start. This is a security requirement that prevents unauthorized access to the application. The JARs can also be signed using the 'jarsigner' utility that comes with Java SDK.

5. Host the created build directory using a Web Server. After hosting, the URL that points to the build directory is referred to as the BASE_URL of the installer.

6. Open the file “build/proto_metadata/Metadata/product-installer.jnlp” and replace all occurrences of ${BASE_URL} with the URL that points to the build directory.

7. Start the Web Server.

8. Use Java Web Start (javaws) to invoke the installer. For example, if the BASE_URL is http://somehost.com:8080/sampleproduct, then the command for invoking the installer would be
javaws http://somehost.com:8080/sampleproduct/proto_metadata/Metadata/product-installer.jnlp

Note: openInstaller makes extensive use of JAXB, which is included as part of the Java SDK only from version 1.6.0. So, the sample product installer would only work with Java Web Start version 1.6.0 or higher.

Future Enhancements to JNLP support

1. The EngineBootstrap and Orchestrator classes have code that does things differently for the WebStart mode and the normal mode. The ideal design and implementation should allow the installer to run seamlessly in both modes, without having to write mode-specific code. The use of constructs like
if (webstart) {
// do like this
} else {
// do it differently
}
would be eliminated.

2. The use of platform-independent product zip files for the sample product installer would introduce the flexibility to test the installer hosted at a particular source on any client machine.

3. Moving forward, it would be ideal to have the product and installer metadata packaged as jars. It has two advantages: a) Hosting and maintaining a single jar file is easier than having to maintain hordes of individual files. b) Enhances installer performance by eliminating latency / response gaps while navigating between pages.

4. A WebStart-based installation that uses stream-formatted packages on Solaris causes pkgadd to fail since the -r option (that is used to specify response files) doesn't work for web-based sources. This would be fixed so that stream-formatted packages are successfully installed over HTTP.

SwiXML, the open-source software used to build GUIs declaratively, now gives a foreword about openInstaller in its homepage!

The foreword reads,

"GlassFish is the open source community based implementation of Java EE 5. GlassFish has a few tools projects, one of which is openInstaller.

The openInstaller project provides the framework for developers to create cross platform installations; it is a part of the GlassFish community of projects, and now includes and uses SwiXml."

Thanks, Wolf!

Guess what? We're back with the next minor version release of openInstaller: 0.9.1! The source and binaries of version 0.9.1 is now available for download.

Try openInstaller 0.9.1 now to discover cool new features like

1. Upgrade using legacy descriptors: Just include legacy descriptors that describe older versions of your product & you can now do an upgrade to the version that comes with your installer. openInstaller engine, now, has added capabilities to detect the presence of product versions that you specify in your legacy descriptors.

2. Detection of installed JDKs: You might have bundled a version of JDK along with your product, but the user might just want to use the one that he/she already has on his/her system. The new JDK Selection page, based on Netbeans' JDK detection algorithm, displays the list of JDKs detected in the system. The user can either choose one from the list or specify a JDK path manually or just simply let the installer install the bundled JDK.

3. Add/Remove Programs entries in Windows: As part of specifying Desktop Integration information in the config (.xcs) files, you can now include additional info for making your product appear in the Add/Remove Programs section in Windows.

4. Summary page enhancements: You now get to see a crisp and concise text summary of the installation status, instead of just a link to an external summary page. Also displayed is the absolute location of the log files.

5. SIMS metapackages count reduction on Linux: Linux metapackages count for SIMS was much higher than on Solaris. This has been reduced.

Apart from the features highlighted above, a few bugs have also been fixed. The packaging of the bundles have also been worked upon to remove all impertinent information that's likely to confuse new developers.

Desktop integration is a term that collectively refers to the set of tasks that the install framework does to configure / unconfigure the install image. In the simplest of cases, it could mean the creation of a few shortcuts to the installed software's executable in the desktop and/or in the user's Start menu or Programs menu. However, in quite a few other cases, it could also mean tasks like starting / stopping a few services on system startup / shutdown and installing the application into the system tray (or notification area).

DESKTOP ENVIRONMENTS

Desktop integration depends primarily on detecting the current environment that is installed on the target system. While Windows has its own unique desktop environment, UNIX-based operating systems like Solaris and Linux come with their own different flavors of desktop environments, the most famous of which are the GNOME and the KDE desktops. Currently openInstaller supports the following features on two desktop environments.

• GNOME – creation and removal of desktop & Launch menu / Applications shortcuts.
• Windows – creation and removal of desktop shortcuts, Start menu / Programs shortcuts & Add/Remove Programs entries.

THE GNOME IMPLEMENTATION

Creation of a shortcut in GNOME involves creation of a special kind of file called the .desktop file. The location where the .desktop file is installed or placed determines where the shortcut appears (in the user's desktop or Applications menu).

Structure of a .desktop file

A .desktop file looks very similar to a properties file whose first line is always [Desktop Entry] and has values defined for a few important keys like
Name - the name that appears in the shortcut.
Type - either of Application/Link/Directory.
Icon - the image file to be used as icon for the shortcut.
Exec - the executable to be run if this shortcut is clicked.

Shown below is a sample .desktop file.
[Desktop Entry]
Name=Calculator
Comment=A tool used for mathematical calculations.
Type=Application
Icon=/usr/share/pixmaps/gnome-calc.png
Exec=gnome-calc
RunInTerminal=true

Submenus & .directory files

In order to create shortcuts under custom submenus under the Applications menu, special files called .directory files need to be created. The structure of a .directory file is pretty much the same as a .desktop file, except that the value of the Type property is always “Directory” and the filename has a .directory extension.

Standard locations for .desktop & .directory files

The .desktop file that contains the shortcut information should be placed in the appropriate directories depending on whether it is a root or a user installation. The standard locations are given below.

Vfolders and .vfolder-info files

Start menu shortcuts creation in GNOME for user installations involves much more than simply installing a .desktop file in the appropriate folder. Every submenu under the applications menu is a virtual folder and hence any new submenu that should appear under the Applications menu should first be merged with the main Applications menu.

User installations can do this merging by adding suitable entries for the .desktop and .directory files, to an important file called applications.vfolder-info, which resides under ~/.gnome2/vfolders. It's basically an XML file that conforms to the vfolder-info DTD that is specified as part of Freedesktop standards.

Note: Vfolders is a standard that is deprecated since GNOME version 2.10.

Menus and .menu files

As of GNOME version 2.10 and above, custom submenus under the Applications menu can be created and merged with the main Applications menu by means of special files called .menu files. The standard location for placing these .menu files is /etc/xdg/menus/applications-merged for root user and ~/.config/menus/applications-merged for non-root user. A .menu file is a simple XML file that conforms to the menu specification DTD that is again specified as part of Freedesktop standards.

THE WINDOWS IMPLEMENTATION

Unlike GNOME, the creation of shortcuts in Windows is pretty simple and straightforward. All that needs to be done is to create a shortcut or a link in the appropriate folder by means of executing a creation or deletion script. The parameters required to create/remove the shortcut are used to create a VB Script file (.vbs), which is then executed in the user's environment using the Windows Script Host (WSH) framework. The “cscript” command of the Windows Script Host is being used for this purpose.

Given below is an example script that creates a shortcut on all users' desktop.

Dim WSHShell, LinkFile
Set WSHShell = Wscript.CreateObject("WScript.Shell"
LinkFile = “C:\Documents and Settings\All Users\Desktop\Java Homepage.url”
Set Link = WSHShell.CreateShortcut(LinkFile)
Link.TargetPath = “http://java.sun.com”
Link.Save

The source is finally out!

Following the binaries, the source code for version 0.9.0 of openInstaller is now available for download in the Downloads section.

Developing GUI applications with Java Swing can be as challenging as it is fun. Much of the challenge in it lies in the fact that every change done to Swing code requires a recompilation. Most of today's applications warrant frequent changes to the UI, thereby making the life of a Swing programmer difficult. Would it not be great if writing UI code were as simple as writing XMLs? Such a wishful thought inspired Wolf Paulus to create SwiXML, an open-source software which combines the power and robustness of Java's Swing with XML's ease-of-use.

openInstaller leverages these advantages of SwiXML completely by employing a UI model built internally using SwiXML. Complex logic like defining layouts & positioning the components / widgets inside the panels is already built into openInstaller. This enables install application developers to just focus on other important aspects of an installer without worrying too much about the UI. openInstaller provides them with an interface that is based on the Java Desktop System Configuration Manager specification. Installer developers just use this interface to define their UI pages at a high-level.

For example, to create a UI page like the one shown below,

one would have to define an XML something like what follows..

<apt:template apt:name="appserver"  xmlns:apt="http://www.sun.com/jds/apoc/2004/template"
    xmlns: xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:oor=http://openoffice.org/2001/registry>
  <apt:category apt:name="Application_Server" apt:label="ApplicationServer" >
    <apt:page apt:name="Configuration_Item" apt:label="Configuration Settings" >
      <apt:section apt:name="appserver" apt:label="Application Server" >
        <apt:property apt:name="AS_ADMIN_USER" apt:label="Administration User"
                    apt:dataPath="AppServer.AS_ADMIN_USER"
                    apt:type="xs:string" >
          <apt:visual>
            <apt:textField apt:columns="15" apt:toolTip="Application Server Administration User."/>
          </apt:visual>
        </apt:property>
        <apt:property apt:name="AS_ADMIN_PASSWORD" apt:label="Administration Password" apt:dataPath="AppServer.AS_ADMIN_PASSWORD" apt:type="xs:string" >
          <apt:visual>
            <apt:password apt:columns="15" apt:toolTip="Application Server Administration Password."/>
          </apt:visual>
        </apt:property>
        <apt:property apt:name="AS_CONFIRM_PASSWORD" apt:label="Confirm Password" apt:dataPath="AppServer.AS_CONFIRM_PASSWORD" apt:type="xs:string" >
          <apt:visual>
            <apt:password apt:columns="15" apt:toolTip="Confirm Administration Password."/>
          </apt:visual>
        </apt:property>
        <apt:property apt:name="AS_ADMIN_PORT" apt:label="Administration Port"
apt:dataPath="AppServer.AS_ADMIN_PORT" apt:type="xs:int" >
          <apt:visual>
            <apt:textField apt:columns="15" apt:toolTip="Application Server Administration Server port."/>
          </apt:visual>
        </apt:property>
        <apt:property apt:name="AS_HTTP_PORT" apt:label="HTTP Port"         apt:dataPath="AppServer.AS_HTTP_PORT" apt:type="xs:int" >
          <apt:visual>
            <apt:textField apt:columns="15" apt:toolTip="Application Server Http Server instance Port."/>
          </apt:visual>
        </apt:property>                
      </apt:section>
    </apt:page>
  </apt:category>
</apt:template>

An <apt:page> can contain multiple <apt:section> elements, each of which would visually correspond to a tab in a tabbed pane. Each <apt:property> element denotes a single configurable visual element on the page. The value of the apt:dataPath attribute represents the configuration variable name that can be used by the product configurator.

The above interface also supports user-input validation by means of built-in constraints as well as custom-validation scripts using Beanshell.

Efforts for developing NetBeans plugins that help in the creation of these UI-definition XMLs using a simple drag-and-drop mechanism are already underway, so openInstaller aficionados have a lot to look forward to in our future releases!

The URL http://openinstaller.org now redirects to the openinstaller.dev.java.net site's front page, thanks to Annie Putz, Sun's Domain Manager.

Project Purple Haze, a project aimed at providing a panacea for all installation pain-points, is all set to go open-source on 1st May, 2007.

Watch out this space for more updates from me about openInstaller.

You're also highly encouraged to join the community, provide suggestions and feedback, contribute to it & most importantly, "spread the word around"!