some libxslt build plans

  1. libxslt01 (ready for qa) would introduce the libxslt module into OOo, pending sun legal work to make it into OOo
  2. If that goes ahead then libxslt02 (created and ready to roll post libxslt01) builds on this to
    1. make the collection of xsltproc patches and alternative targets the default and replace the current selection of java based tooling for officecfg, readlicence_oo and filter, etc. Unifying the more or less default external community build defaults with that of Sun’s internal ones, and giving a speed boost for officecfg building
    2. replace the runtime usage of sablot with that of libxslt. Shrinks the size of OOo a little for the system-using world, and seating us on a more contemporary solution.
  3. nativehelplinker (#i70155) would then also build on libxslt01 to replace the XmlSearch and java helplinker programs with a native libxslt/libxml2 using app giving a significant speed boost for building the multiple language helpcontent2 help files, it might be interesting at that stage to take stock and see if xt.jar is then still used by anything.
  4. nativehelplinker would remove the need for db4-java, so bumping the internal db4 to a later version of db4 and dropping building db4-java becomes easier. That would hoover up some of those outstanding db4 upgrade patches for xmlhelp that are floating around

One Response to “some libxslt build plans”

  1. Svante Schubert says:

    Hi Caolan,

    xt.jar is no longer in need, actually it has already been removed in an issue – although not integrated:
    http://www.openoffice.org/issues/show_bug.cgi?id=51803
    (take a look at the end).

    BTW we are currently using Java Xalan processor and Java Xerces parser for the XML based filters in the Office runtime.

    Bests,
    Svante

Leave a Reply