ODF Toolkit/Efforts/Three-Layer OOo
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) andprogram/unopkg.bin
-
program/about.bmp
andprogram/intro.bmp
-
program/bootstraprc
(Unix) resp.program/bootstrap.ini
(Windows):-
ProductKey
,ProductPatch
,ErrorReportServer
,ErrorReportPort
,InstallMode
, andUserInstallation
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
, andHideEula
are potentially brand specific. -
MacOSXIntegrationUserFile=${$ORIGIN/bootstraprc:UserInstallation}/user/macosxrc.txt
andMacOSXIntegrationDefaultFile=${$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
, andExtensionUpdateURL
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 aProductBuildid
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
, andSecurity
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 singleColorScheme.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
, andProduct.ooOpenSourceContext
appear to be potentially brand specific. -
Office
,L10N
,Configuration
, andMigration
appear not to be brand specific but are just retained in this file.
-
- the complete
share/extension
(containinginstall
sub-directory) andshare/uno_packages
(containingcache
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
- the complete
share/xdg
directory, containingbase.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
andREADME
- 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
, whereVERSION
is replaced with2.4
in code>desktop/scripts/makefile.mk</code>:1.11.184.1. TODO: the version number must not be fixed in themakefile.mk
as it is done for now.
- On Unix, this is a symbolic link to
-
program/fundamentalrc
(Unix) resp.program/fundamental.ini
(Windows):-
BRAND_BASE_DIR=$ORIGIN/..
points at the Brand layer base directory (it is used to locateUNO_SHARED_PACKAGES=$BRAND_BASE_DIR/share/uno_packages
andUNO_USER_PACKAGES=${$BRAND_BASE_DIR/program/bootstraprc:UserInstallation}/user/uno_packages
in the OOo-Basis layerprogram/unorc
, and to locate$BRAND_BASE_DIR/program/bootstraprc
and$BRAND_BASE_DIR/program/versionrc
in the OOo-Basis layerprogram/configmgrrc
). -
CustomDataUrl=${BRAND_BASE_DIR}
activates the Brand layershare/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 theOOO_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
, andURE_BIN_DIR
forward toprogram/fundamentalbasisrc
(Unix) resp.program/fundamentalbasis.ini
(Windows), an adapted version of thefundamentalrc
/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.
- Especially with various binary executables (like
- 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 plainLoadLibrary
call), but not for executables in the OOo-Basis layer (if there are any). - TODO:
/DELAYLOAD:uwinapi.dll
is needed on all Windows platforms, includingwntgcci6
.
♦ 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 APP
nRPATH
/SHL
nRPATH
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
andURE_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 layershare/config
entry (i.e., shared settings would be per–Brand-layer), andURE_OVERRIDE_JAVA_JFW_USER_DATA
is set to a UserInstallation/user/config
entry. - So that
javaldx
called from the start scripts behaves correctly, aprogram/javaldxrc
is added to the Brand layer (on those platforms that actually usejavaldx
), containing a definition ofURE_BOOTSTRAP
and thus linking to thefundamentalbasisrc
/fundamentalrc
settings. - The
sal
bootstrap
code is extended with an internal feature to allowINIFILEPATH
to contain a system path to the ini-file, similar to howINIFILENAME
can contain the URL of the ini-file. This is used to pass the system path of thejavaldxrc
tojavaldx
(as computing a URL from a system path is non-trivial).
♦ On Mac OS X, a mechanism was still missing how executables and dynamic libraries in one layer can access dynamic libraries in another layer. This has now been fixed.
- Building on the existing
SHL
nRPATH
stuff, the install name of every dynamic library being built is set to a “@
” followed by fifty “_
” followed by the expansion of the relevantSHL
nRPATH
(i.e., eitherURELIB
orOOO
). The resulting very long name containing fifty underscores is needed so that someinstall_name_tool -change
call later on does not complain that “larger updated load commands do not fit.” - Then, building an executable or dynamic library:
- a re-written
solenv/bin/macosx-dylib-link-list.pl
scans the preliminary linker command line for any-L
and-l
switches and adds to the final linker command line the necessary-dylib_file
arguments for the transitive hull of all (indirectly) included dynamic libraries; - a new
solenv/bin/macosx-change-install-names.pl
post-processes the generated executable or dynamic library, replacing the recorded install names of linked-against dynamic libraries with install names that will work in the final, installed products. To do so, it uses three pieces of information for every changed install name: whether the entity being post-processed is an executable (app
) or a dynamic library (shl
), theAPP
/SHL
nRPATH
of the entity being post-processed (UREBIN
,URELIB
,OOO
, orBRAND
), and theSHL
nRPATH
of the linked-against dynamic library (recoverd from the recorded install name,URELIB
orOOO
). This gives a matrix of rules how to rewrite the path prefixes of install names (missing entries are invalid):-
app/UREBIN/URELIB
→@executable_path/../lib
-
app/OOO/URELIB
→@executable_path/../ure-link/lib
-
app/OOO/OOO
→@executable_path
-
app/BRAND/URELIB
→@executable_path/../basis-link/ure-link/lib
-
app/BRAND/OOO
→@executable_path/../basis-link/program
-
shl/URELIB/URELIB
→@loader_path
-
shl/OOO/URELIB
→@loader_path/../ure-link/lib
-
shl/OOO/OOO
→@loader_path
-
- (The good old monolithic OOo is kept alive for now by adding a fake
ure-link/lib
→../program
symbolic link to its installation set.)
- a re-written
- Mac OS X 10.5 reportedly also supports an
RPATH
similar to ELF, but using it instead of fiddling with the install names would violate the Mac OS X 10.4 baseline. - Using install names this way breaks down for external libraries (that are built with their own mechanisms):
- For STLport, this is circumvented by making
--without-stlport
the default for Mac OS X (TODO: and probably completely removing--with-stlport
for that platform), see also CWSs newportstl and stl4leopardppc. - TODO: Some external libraries have absolute install names starting with
/usr/local/lib
and need to be addressed. - TODO: The other external libraries have install names starting with
@executable_path
and need to be addressed.
- For STLport, this is circumvented by making