testtools/source/cliversioning/readme.txt

   1 #
   2 # This file is part of the LibreOffice project.
   3 #
   4 # This Source Code Form is subject to the terms of the Mozilla Public
   5 # License, v. 2.0. If a copy of the MPL was not distributed with this
   6 # file, You can obtain one at http://mozilla.org/MPL/2.0/.
   7 #
   8 # This file incorporates work covered by the following license notice:
   9 #
  10 #   Licensed to the Apache Software Foundation (ASF) under one or more
  11 #   contributor license agreements. See the NOTICE file distributed
  12 #   with this work for additional information regarding copyright
  13 #   ownership. The ASF licenses this file to you under the Apache
  14 #   License, Version 2.0 (the "License"); you may not use this file
  15 #   except in compliance with the License. You may obtain a copy of
  16 #   the License at http://www.apache.org/licenses/LICENSE-2.0 .
  17 #
  18
  19
  20 WINDOWS ONLY, no other platforms
  21
  22
  23 This test checks if the cli assemblies and their policy files are installed in the
  24 GAC and if the policy files are correct. The office must be installed with complete
  25 system integration. That is, one does not use setup /a for starting the
  26 installation.
  27
  28 In OOo 3.0 there was a breaking change so that the test created for previous
  29 version do not work anymore. To use these old tests one needs to install a
  30 version of OOo less than v 3.0. Then one needs to check out the cli_ure module
  31 for that version. The tests are contained in cli_ure/qa/versioning.
  32
  33 In the sub directory version_libs are libraries which are linked with (referencing)
  34 cli_cppuhelper
  35 cli_basetypes
  36 cli_ure
  37 cli_uretypes
  38 cli_oootypes
  39
  40 They are named version_3_0_0 etc, where the name indicates the version of the
  41 office for which they were initially build. If there are only the assemblies
  42 for example OOo2.0.2 installed and a client was build with the assemblies from
  43 OOo2 then the policy assemblies must make the correct redirection.
  44
  45 When calling dmake then the executable runtest.exe and version_current.dll are
  46 build. When runtest runs then it loads all dlls, which names start with
  47 "version", from the same directory and tries to run a particular test code
  48 which is only available in the version_xxx.dll s. The code in the
  49 version_xxx.dlls uses the cli default bootstrap mechanism to find the office
  50 installation and start the office. When running runtest in a build environment
  51 then it may use the wrong libraries for bootstrapping in which case the test
  52 fails. Then one has to set PATH which must point to the program directory of
  53 the office installation. For example:
  54
  55 set PATH=d:\office\program
  56
  57 runtest stops when a test failed to run. It writes error information to the
  58 console which shows which version_xxx.dll failed to run and if this was due to
  59 a referenced assembly that could not be loaded. This would be the case if such
  60 an assembly or the policy assembly is not properly installed or the redirection
  61 in the policy assembly is wrong.
  62
  63 The version_current.dll references the assemblies in the current build
  64 environment. version_current.dll is also executed when runtest is started.
  65
  66 To run the whole test one can either
  67 1. start testools/wntmsci11.pro/bin/runtests.exe in a console where no
  68 environment is set.
  69 2. Call dmake run in testools/qa/cliversions
  70
  71 For a limited test one can call in this directory
  72 dmake run office=d:\office
  73 There must not be an office installed in the system (the assemblies from the GAC
  74 would then be used). Only the test with the version_current.dll will succeed
  75 because there are no policy files installed. This test requires that all
  76 assemblies are copied next to runtests.exe - the makefile will do that.
  77
  78 The parameter office must be a system path to the office installation
  79 directory. The java code calls runtest and also sets PATH so that the test
  80 works in the build environment. It also sets UNO_PATH so that the office will be
  81 found. If the test says that it failed, then one should run runtest directly
  82 because it puts out more information.
  83
  84
  85
  86 Creating a new version_xxx.dll
  87 ==============================
  88 When a version of our assemblies changes then one should provide a new version dll which test exactly the assemblies with the changed version. This is easily done:
  89 1. set the build environment in which the new versions are effective.
  90 2  call: dmake name=version_xxx.dll
  91 3. copy the new version dll from the output tree into qa/versioning/version_libs
  92 4. commit the new version.dll using the -kb switch (only when creating the new file : cvs new -kb version_3_1_0.dll)
  93