In the future “OpenOffice.org Extensions” will be more and more important for OpenOffice.org. Extensions can be added to or removed from the installed product using the “Extension Manager”. But it can also happen, that selected extensions are already part of the installation set. This extensions have to be registered into the OpenOffice.org during the installation. If you plan to create your own installation sets using extensions, you should have a look at

http://wiki.services.openoffice.org/wiki/Extensions_Integration_into_Installation_Set

where you can find the latest information about the integration of extensions into OpenOffice.org installation sets.

Currently OpenOffice.org does not support the patch mechanism introduced by Microsoft with its Windows Installer technology: the Windows Installer patch files *.msp. Nevertheless in cws native82 (integrated into src680m212) we added some code, that makes the usage of Windows Installer patch technology possible in the future. Together with our friends from Novell, code changes were done in the packaging process to change the Windows Installer database (the msi file in the installation set) in that way, that a Windows Installer patch can be created. The msp file is generated as a difference of at least two installation sets, the source and the target. Of course it can be necessary and is also necessary for OpenOffice.org, that there is more than one source. We would require a patch, that updates from OOo 2.0, OOo 2.0.1, OOo 2.0.2, ... , OOo 2.1 to the current version OOo 2.2. Additionally there are additional source installation sets, because of the huge number of languages, in which OpenOffice.org is available.

The code changes in the OpenOffice.org msi database are necessary, because the msp creation process requires the following settings:

• Each file has to be in the same cabinet file in the source and the target installation path. This is currently fixed by reducing the number of cabinet files to one.

• The table “FileHash” in the Windows Installer database has to be used.

• The ProductCode has to be kept constant for all OpenOffice.org releases.

• The default destination directory of all OpenOffice.org version has to be kept contant. This requires for example the usage of “OpenOffice.org 2”.

• The primary key in the table “File” in the Windows Intaller database has to be kept constant.

• The short names (8+3 syntax) in the tables “File” and “Directory” have to be kept constant.

• The globally unique IDs (GUID) of all components in the Windows Installer database have to be kept constant.

Unfortunately this changes cannot be included into the standard packaging process, because it would break the existing update process, that is a “Major Upgrade” in Windows Installer terminology. And according to the huge number of changed files from OpenOffice.org 2.0 to OpenOffice.org 2.2 it is advantageous to use a Major Upgrade instead of a patch. Additionally it is necessary for Windows Installer patch creation, that not only the target installation set, but also all the source installation sets are already built with the constraints listed above. Therefore this changes will not be standard behaviour of OpenOffice.org installation sets created by Sun Microsystems during OpenOffice.org 2.x time frame.

But if you want to investigate the Windows Installer patch technology for OpenOffice.org you can do so after integration of cws native82, by using the following settings:

1. “set PREPARE_WINPATCH=1”

2. “set PREVIOUS_IDT_DIR=[path_to_the_idt_directory_of_the_source_installset]”> . The path PREVIOUS_IDT_DIR has to contain the files File.idt and Director.idt of the source installation set. The path ends with something like: instsetoo_native\wntmsci10.pro\OpenOffice\msi\idt_files\[alllang]\[speciallang]

3. Additionally it is necessary to use the file “components.txt” from the source installation set for the creation of the target installation set. You find this file in instsetoo_native\wntmsci10.pro\OpenOffice\msi\info_files. Before starting creation of the target installation set copy it to instsetoo_native\inc_openoffice\windows\msi_templates

After you have created a source installation set and a target installation set this way, you can start to create the Windows Installer patch, for example with the tool msimsp.exe from Windows Installer SDK and a pcp file that needs to be created. But this process of patch creation is documented somewhere else ;-)

In the child work space “native82” from the installation project, we will improve the capabilities of an OpenOffice.org that is created with package format “installed”. This can be used first of all by developers, but basically this feature can be used by everyone who has a solver available. We introduce two additional feature, to get a faster, more usable and more complete OpenOffice.org without creating an installation set.

1. Introduction of environment variable “LOCALINSTALLDIR”:

If you set this environment variable for example on Windows platforms to “c:\programs\myoffice”, this directory will be used as root directory for the OpenOffice.org installation. This accelerates the installation process and solves additionally the problem of the long installation pathes, if the installed product is created in the output tree of instsetoo_native. It could happen, that the OpenOffice.org did not start correctly, because there were very long pathes for the OpenOffice.org configuration.

2. Registration of OpenOffice.org Extensions after all files are copied:

All extensions located in the sub directory “share\extension\install” will be registered into OpenOffice.org after all files are copied locally. This simplifiles the testing of new extensions. And because the program “unopkg” of the installed product is called, this works reliable on every platform. If you are fast enough, you can simply put your new extension during the copying process into the directory “ share/extension/install” and let it be registered by the installation process. For this testing purposes, this file even does not need to be defined in scp2 project.

This is a really fast process the get an installed OpenOffice.org. No root privileges are required and no systemintegration is done. Even the user directory is created locally inside this product. This is achived by setting the path to the user installation in the file “bootstraprc” (“bootstrap.ini”) to $ORIGIN/../OpenOfficeorg2 . So you can simply remove the directory to get rid of this installation. Of course this changes are also valid for the package format “archive”, which simply create a tar.gz or a zip file at the end of the installation process. But using the format “installed” now becomes a real alternative for developers to the existing installation types without root privileges. Of course the latter are still required, if you want to use an existing installation set. But during development process in a child work space, we recommend to use the following scenario:

1. “setenv LOCALINSTALLDIR <localofficedir>”

And in the directory “ instsetoo_native/util” start the installation process with:

2. “dmake openoffice_en-US PKGFORMAT=installed”