Difference between revisions of "ODF Toolkit/Efforts/Three-Layer OOo"

Revision as of 15:35, 7 January 2008

After OOo without URE this is the next step in the broader Packaging Modularization project. The goal is to replace the special OOo product “OOo-wo-URE” from OOo without URE with split products for the OOo Basis and Brand layers:

• As the lowest layer, an installed URE is required as a prerequisite.
• As the middle layer, the new product “OOo-Basis” contains the bulk, brand-independent OOo functionality.
• As the top layer, brand specific new products like “OpenOffice.org-Brand”, “BrOffice-Brand”, or “StarOffice-Brand” each require OOo-Basis as a prerequisite, and can be installed in parallel and used concurrently.

For now, OOo-Basis (ooobasis_locale in instsetoo_native/util/makefile.mk:1.80.8.1) and some example brand packages (OpenOffice.org-Brand, ooobrand_locale in instsetoo_native/util/makefile.mk:1.80.8.1; and Sun-internal StarOffice-Brand, sobrand_locale in instset_native/util/makefile.mk:1.62.4.1) are just special additional products (replacing the former OOo-wo-URE special product), but if things work out fine, they should replace the normal OOo in the future (like for OOo 3).

Work is done on CWS sb83.

♦ Files that moved from plain OOo (i.e., the new OOo-Basis layer) into the new Brand layer:

• program/soffice (Unix) resp. program/soffice.exe (Windows)
• program/soffice.bin
• program/unopkg (Unix) resp. program/unopkg.com (Windows)
• program/unopkg.exe (Windows only) and program/unopkg.bin
• program/about.bmp and program/intro.bmp
• program/bootstraprc (Unix) resp. program/bootstrap.ini (Windows):
  • ProductKey, ProductPatch, ErrorReportServer, ErrorReportPort, InstallMode, and UserInstallation are potentially brand specific.
  • BaseInstallation=${OOO_BASE_DIR} appears not to be brand specific but is just retained in this file.
• program/sofficerc (Unix) resp. program/soffice.ini (Windows):
  • ProgressBarColor, ProgressSize, ProgressPosition, ProgressFrameColor, Logo, and HideEula are potentially brand specific.
  • MacOSXIntegrationUserFile=${$ORIGIN/bootstraprc:UserInstallation}/user/macosxrc.txt and MacOSXIntegrationDefaultFile=${$ORIGIN/bootstraprc:BaseInstallation}/presets/macosxrc.txt appear not to be brand specific but are just retained in this file.
• program/versionrc (Unix) resp. program/version.ini (Windows):
  • buildid, ProductPatch, ProductSource, ProductCode, UpgradeCode, ProductMajor, ProductMinor, ProductBuildid, AllLanguages, MsiProductVersion, UpdateURL, UpdateID, UpdateUserAgent, and ExtensionUpdateURL appear to be potentially brand specific. (TODO: are they all? It has to be clarified what exactly their semantics are, and whether they are indeed brand specific, or maybe need to be split in two—like a ProductBuildid for the OOo-Basis layer and the Brand layer each.)
  • OOOBaseVersion is not brand specific but is just retained in this file.
• share/registry/data/org/openoffice/Office/Common.xcu:
  • Help.Registration.URL is potentially brand specific.
  • View, Menus, Forms, Startup, Save, and Security appear not to be brand specific but are just retained in this file.
• share/registry/data/org/openoffice/Office/Compatibility.xcu:
  • WriterCompatibilityVersion.OOo11 is potentially brand specific.
  • AllFileFormats appears not to be brand specific but is just retained in this file.
• share/registry/data/org/openoffice/Office/UI.xcu:
  • ColorScheme.CurrentColorScheme (and thus the name of the single ColorScheme.ColorSchemes group) is potentially brand specific.
  • FilterClassification appears not to be brand specific but is just retained in this file.
• share/registry/data/org/openoffice/Setup.xcu:
  • Product.ooName, Product.ooSetupVersion, Product.ooSetupVersionAboutBox, Product.ooSetupExtension, Product.ooXMLFileFormatVersion, Product.ooXMLFileFormatName, and Product.ooOpenSourceContext appear to be potentially brand specific.
  • Office, L10N, Configuration, and Migration appear not to be brand specific but are just retained in this file.
• the complete share/extension (containing install sub-directory) and share/uno_packages (containing cache sub-directory) directories:
  • The share/extension/install directory can contain brand specific Extensions that are deployed shared at installation time.
  • This implies that the shared Extension layer (share/uno_packages) is in the Brand layer, not the OOo-Basis layer. (TODO: a future extension might be to add a third Extension layer in the OOo-Basis layer.)
• the complete share/xdg directory, containing base.desktop, calc.desktop, draw.desktop, extension.desktop, impress.desktop, math.desktop, printeradmin.desktop, qstart.desktop, writer.desktop
  • math.desktop is not present in StarOffice and StarOffice-based products
  • TODO: in general, how will desktop integration be handled (e.g., there can only be one /usr/bin/soffice symlink)?

Newly added files in the Brand layer:

• LICENSE and README
  • TODO: see issue 84336.
• basis-link
  • On Unix, this is a symbolic link to ../openoffice.orgbasis2.4. TODO: the version number must not be fixed in the .scp file as it is done for now. TODO: instead of having a hard-coded (relative) path installed, the symbolic link could be computed at installation time, based on package information (where are the OOo-Basis packages installed to?).
  • On Windows, this is a plain text file containing ..\OpenOffice.org Basis VERSION, where VERSION is replaced with 2.4 in code>desktop/scripts/makefile.mk</code>:1.11.184.1. TODO: the version number must not be fixed in the makefile.mk as it is done for now.
• program/fundamentalrc (Unix) resp. program/fundamental.ini (Windows):
  • BRAND_BASE_DIR=$ORIGIN/.. points at the Brand layer base directory (it is used to locate UNO_SHARED_PACKAGES=$BRAND_BASE_DIR/share/uno_packages and UNO_USER_PACKAGES=${$BRAND_BASE_DIR/program/bootstraprc:UserInstallation}/user/uno_packages in the OOo-Basis layer program/unorc, and to locate $BRAND_BASE_DIR/program/bootstraprc and $BRAND_BASE_DIR/program/versionrc in the OOo-Basis layer program/configmgrrc).
  • CustomDataUrl=${BRAND_BASE_DIR} activates the Brand layer share/registry as an additional configuration layer.
  • OOO_BASE_DIR=${BRAND_BASE_DIR}/basis-link (Unix) resp. OOO_BASE_DIR=${.link:${BRAND_BASE_DIR}/basis-link} (Windows) fixes the OOO_BASE_DIR already introduced in OOo without URE. See below for the ${.link:...} hack.
  • UNO_SHARED_PACKAGES_CACHE, UNO_USER_PACKAGES_CACHE, URE_MORE_TYPES, URE_MORE_SERVICES, URE_MORE_JAVA_TYPES, URE_MORE_JAVA_CLASSPATH_URLS, and URE_BIN_DIR forward to program/fundamentalbasisrc (Unix) resp. program/fundamentalbasis.ini (Windows), an adapted version of the fundamentalrc/fundamental.ini already introduced in OOo without URE.

♦ The executables that make up the client interface of a (branded) office suite need to be in the Brand layer:

• They are expected at well-defined places so that clients can interact with them.
• They are potentially brand specific (e.g., on Windows they will contain brand specific application icons).

TODO: it is unclear what executables exactly make up the interface, see The interface of OOo; for now, I just take soffice and unopkg.

♦ The executables ultimately called from the above client interface executables (e.g., soffice.bin and unopkg.bin, and on Windows also unopkg.exe) could theoretically be in the OOo-Basis layer. However, as in many code places they use various “look next to me” mechanisms to locate other files in the Brand layer, it appeared easiest to just move them to the Brand layer, too. (TODO: this decision may need to be re-evaluated.)

♦ Conversely, until now only two places in the code have been identified where “look next to me” mechanisms had to be replaced with mechanisms to epxlicitly address the OOo-Basis or the Brand layer:

• In framework::SubstitutePathVariables, compute $(prog)$ as $(inst)/program (making both $(inst) and $(prog) point into the OOo-Basis layer).
• In module shell ShellExec, the URL launchers are now looked for in the $OOO_BASE_DIR/program directory, instead of next to the executable.

♦ What shall be the paths where the tree layers are installed, and is it necessary to encode any version numbers in those paths?

• URE only ever changes compatibly, so no version number is required in its path (i.e., multiple applications can share a single URE installation, as long as its minor version number is at least as large as the largest one required by any of the applications).
• There is no such compatibility guarantee for the interface between the OOo-Basis layer and the Brand layer:
  • Especially with various binary executables (like soffice.bin) in the Brand layer, controlling a compatible interface between the two layers seems extremely hard and error prone.
  • When various Brand layers (of different minor versions) are installed in parallel on top of a single OOo-Basis layer (which needs to be at least of the highest required minor version), it might be unexpected by clients that Brand products of lower minor version nevertheless much behave like products of a higher minor version (e.g., suddenly offer features at the UI that were only introduced in later OOo minors).
  • The above points suggest that the major.minor OOo version should be encoded in the OOo-Brand layer path. However, that has the drawback that a software artefact used by a client to update an installed branded office suite probably cannot be kept small (by only including data that has really changed), as the paths of all files in the OOo-Brand layer change (even if their content does not change).
  • TODO: A related problem is that for example a StarOffice-Brand layer distributed by Sun will not work on top of an OOo-Basis layer (and maybe not even on top of a URE layer) provided by some Linux distribution, as they have been built from (nominally compatible) OOo sources using different configure switches that potentially break compatibility at the interfaces among the three layers.
• Encoding any version numbers in the Brand layer paths is only necessary if different versions of the same brand shall be installable in parallel, or there shall be small software artefacts to update between different versions (see above). It is a responsibility of the respective brand owners to define policies here. (TODO: define such a policy at least for OpenOffice.org itself.)
• For now, I use the paths:
  • /opt/openoffice.org/ure, /opt/openoffice.orgbasis2.4, and /opt/openoffice.org2.4 (and /opt/staroffice8) on Unix;
  • Program Files\OpenOffice.org\URE, Program Files\OpenOffice.org Basis 2.4, and Program Files\OpenOffice.org 2.4 (and Program Files\StarOffice 8) on Windows.

♦ Delayloading of uwinapi.dll is only needed in a few specific executables (loaders in module desktop; moved everything relevant from module sal there).

• TODO: the delayload hook only looks in ..\→basis-link\→ure-link\bin, which is fine for executables in the Brand layer (and for executables in the URE layer, as an unsuccessful hook call will be followed by a plain LoadLibrary call), but not for executables in the OOo-Basis layer (if there are any).
• TODO: /DELAYLOAD:uwinapi.dll is needed on all Windows platforms, including wntgcci6.

♦ On Windows, the loaders add both ..\→basis-link\program and ..\→basis-link\→ure-link\bin to the front of PATH, failing catastrophically (with a MessageBox based on GetLastError) if the links do not work. TODO: to avoid failure in plain OOo, a fake (.) basis-link and a (non-functional) ure-link are added to plain OOo for now.

♦ Completely removed deprecated pkgchk tool; use unopkg instead.

♦ Start scripts (desktop/scripts/soffice.sh:1.28.34.3, desktop/scripts/soffice_lean.sh:1.9.34.3, desktop/scripts/unopkg.sh:1.6.34.2) look for javaldx in $sd_prog (TODO: to be removed once there is no plain OOo any more) and $sd_prog/../basis-link/ure-link/bin, and for pagein in $sd_prog/../basis-link/program (which also works in plain OOo as a trivial basis-link is also included there for now).

♦ For the APPnRPATH/SHLnRPATH mechanism, added BRAND case ($ORIGIN:$ORIGIN/../basis-link/program:$ORIGIN/../basis-link/ure-link/lib).

♦ To reduce differences among brands, include PyUNO in StarOffice and StarOffice-based products.

♦ New rtl_convertStringToUString converts a byte string to a Unicode string, signalling failure (analoguous to existing rtl_convertUStringToString). Unit tests in sal/qa/rtl/oustring/rtl_OUString2.cxx:1.13.8.1.

♦ Added internal ${.link:...} hack to rtl/bootstrap.h macro expansion to simulate symbolic links under Windows. Unit tests in sal/qa/rtl/bootstrap/rtl_Bootstrap.cxx:1.7.10.2.

♦ In .scp files, after preprocessing, adjacent string literals within a line are merged (analoguous to how C and C++ treat adjacent string literals).

♦ The Linux and Solaris user install scripts now support an additional -a switch to add products into existing trees (so that products for all three layers can be installed into a common, non-default root).

♦ Compared to traditional OOo, the locations where information about a specific JRE to use are stored changed from per–office-installation (optional .../share/config and UserInstallation/user/config) to per–URE-installation (optional /etc/opt/ure and ~/.ure, where multiple Brand layers would share a single set of settings). This caused problems, see issue 84985 and has been changed back to the traditional behavior:

• URE has been extended with URE_OVERRIDE_JAVA_JFW_SHARED_DATA and URE_OVERRIDE_JAVA_JFW_USER_DATA deployment variables, which, if set, override the default shared/per-user locations.
• In fundamentalbasisrc/fundamentalrc, URE_OVERRIDE_JAVA_JFW_SHARED_DATA is set to a potential Brand layer share/config entry (i.e., shared settings would be per–Brand-layer), and URE_OVERRIDE_JAVA_JFW_USER_DATA is set to a UserInstallation/user/config entry.
• So that javaldx called from the start scripts behaves correctly, a program/javaldxrc is added to the Brand layer (on those platforms that actually use javaldx), containing a definition of URE_BOOTSTRAP and thus linking to the fundamentalbasisrc/fundamentalrc settings.
• The sal bootstrap code is extended with an internal feature to allow INIFILEPATH to contain a system path to the ini-file, similar to how INIFILENAME can contain the URL of the ini-file. This is used to pass the system path of the javaldxrc to javaldx (as computing a URL from a system path is non-trivial).