Language

The Free and Open Productivity Suite
Released: Apache OpenOffice 4.1.15

OpenOfficeThe UNO tools
Contents
unoidl

Usage:

The idl compiler transforms interface definitions written in idl into urd files. The urd files are then merged into the type library (rdb). You can find a syntax description for IDL here.

unoidl [flag | file]*

Legal flags:

-E
runs preprocessor only, prints on stdout
-D<name>
defines macro for the preprocessor
-OH<dir>
produce output files in dir (pathname)
-I<dir>
includes dir in search path for preprocessor
-V
prints version info then exits
-Wb,arg1,argn
passes args to BE
-B<backend>
use backend for code generation
supported backend is 'urd' for Uno Reflection Data.
This option is optional because default is using 'urd' backend.
-Mdepend[=match]
generate dependencies for all generated files, to stdout. Files beginning with 'match' are not used for dependencies. No dependencies for the doc backend.
-h
prints this usage message and exits
-v
traces compilation stages
-w
suppresses IDL compiler warning messages
idlc

Usage:

'idlc' is a new idl compiler. We made some changes in the IDL language specification to simplify the syntax.

The idl compiler transforms interface definitions, written in idl, into urd files. The urd files are then merged into the type library (rdb). You can find a syntax description for IDL here.

idlc [-options] file_1 ... file_n | @<filename>

file_1 ... file_n
specifies one or more idl files. Only files with the extension '.idl' are valid.
@<filename>
filename specifies the name of a command file.

Options:

-O<path>
path describes the output directory. The generated output is a registry file with the same name as the idl input file.
-I<path>
path specifies a directory where include files are located, that will be searched by the preprocessor. Multiple directories can be combined with ';'.
-D<name>
name defines a macro for the preprocessor.
-C
generate complete type information, including additional service information and documentation.
-h|?
print this help message and exit.
cppumaker

Usage:

The cppumaker generates a C++ representation for idl types. The cppumaker works on a typelibrary which is generated by the unoidl. It generates the output for all specified types and for all types the specified types depends on.

cppumaker [-options] file_1 ... file_n

Options:

-O<path>
path describes the root directory for the generated output. The output directory tree is generated under this directory.
-T<name>
name specifies a type or a list of types. The output for this [t1;...] type is generated. If no '-T' option is specified, then output for all types is generated.
-B<name>
name specifies the base node. All types are searched under this node. Default is the root '/' of the registry files.
-L|-C
In general, the cppumaker tool generates getCppuType() functions in three ways:

  1. no option (default)
    This generates headers so that UNO runs correctly as long as:
    -- one compiler compiled all code (no bridging needed for inter-component communication)
    -- no marshaling is needed (no bridging needed for interprocess communication)
    -- no scripting is needed (in general, this needs full type description support)
  2. -L (_ONLY_ usable on Windows!)
    This option generates the shortest getCppuType() functions, but needs a running type description manager (+provider) reading all type information from the applicat.rdb! ==> !! Cannot be used at setup startup, because no applicat.rdb is involved at this early stage!!
  3. -C (fully comprehensive type information)
    This options generates the longest form of getCppuType() functions, including a comprehensive description of a type, thus there is no need for a type description manager (+provider) reading types from applicat.rdb:
    -- limitation: only previously used types are provided by the runtime (i.e., only types which were previously registered due to a getCppuType() call are accessible by name)

So, please keep these limitations in mind if you are not sure that there is a running type description manager (+provider) reading from applicat.rdb.
-G
generate only target files which do not exist.
-Gc
generate only target files whose content will be changed.
cunomaker

Usage:

The cunomaker generates a C representation for idl types. The cunomaker works on a typelibrary which is generated by the unoidl. It generates the output for all specified types and for all types the specified types depends on.

cunomaker [-options] file_1 ... file_n

Options::

-O<path>
path describes the root directory for the generated output. The output directory tree is generated under this directory.
-T<name>
name specifies a type or a list of types. The output for this [t1;...] type is generated. If no '-T' option is specified, then output for all types is generated.
-B<name>
name specifies the base node. All types are searched under this node. Default is the root '/' of the registry files.
-U activate the generating of a getCppuType function
-C
In general, the cunomaker tool generates getCppuType_<name>() functions in two ways:

  1. no option (default)
    This generates headers so that UNO runs correctly as long as:
    -- one compiler compiled all code (no bridging needed for inter component communication)
    -- no marshaling is needed (no bridging needed for interprocess communication)
    -- no scripting is needed (in general, this needs full type description support)
  2. -C (fully comprehensive type information)
    This options generates the longest form of getCppuType_<name>() functions, including a comprehensive description of a type, thus there is no need for a type description manager (+provider) reading types from applicat.rdb:
    -- limitation: only previously used types are provided by the runtime (i.e., only types which were previously registered due to a getCppuType() call are accessible by name)

So, please keep these limitations in mind if you are not sure that there is a running type description manager (+provider) reading from applicat.rdb.
-G
generate only target files which do not exist.
-Gc
generates only target files whose content will be changed.
javamaker

Usage:

The javamaker generates the appropriate java file for each idl type. The javamaker works on a typelibrary which is generated by the unoidl. It generates the output for all specified types and for all types the specified types depends on.

javamaker [-options] file_1 ... file_n

Options:

-O<path>
path describes the root directory for the generated output. The output directory tree is generated under this directory.
-T<name>
name specifies a type or a list of types. The output for this [t1;...] type is generated. If no '-T' option is specified, then output for all types is generated.
-B<name>
name specifies the base node. All types are searched under this node. Default is the root '/' of the registry files.
rdbmaker

Usage:

The rdbmaker generates subsets of the typelibrary. The rdbmaker works on a typelibrary which is generated by the unoidl. It generates a subset of the typelibrary which contains all specified types and all types the specified types depends on. This could be used to provide all types and only the necessary types for a component.

rdbmaker [-options] file_1 ... file_n

Options:

-O<fileName>
filename specifies the name of the generated registry or text file.
-L
specifies that only a text file is generated with the names of the specified types and their dependencies. Default is that a registry file will be created.
-T<name>
name specifies a type or a list of types. The output for this [t1;...] type is generated. If no '-T' option is specified, then output for all types is generated.
-FT<name>
name specifies a type or a list of types. For these types, nothing will be generated.
-F<file>
file specifies a text file. For the specified types in this file, nothing will be generated.
-B<name>
name specifies the base node. All types are searched under this node. Default is the root '/' of the registry files.
regcomp

Usage:

Regcomp is a tool to register|revoke external UNO components into|from a registry which is used for an UNO environment.

regcomp -register [-br registryfile] -r registryfile -c locationUrl [-l componentLoaderUrl]

recomp -revoke [-br registryfile] -r registryfile -c locationUrl

Parameters:

  • command:

    -register = register a new extern component.

    -revoke = revoke an extern component.

  • -br registryfile = the name of the registry used for bootstrapping the program. If the bootstrap registry is specified and has the same name as the registration registry, the -r option is optional.
  • -r registryfile = the name of the registry (will be created if it does not exist) where the component should be registered.
  • -c locationUrls = the location of an component (DLL, Class name, or an url of a jar file) or a list of urls separated by ';'s. Note, if a list of urls is specified, the components must all need the same loader.

  • -l componentLoaderUrl = the name of the needed loader, if no loader is specified the 'com.sun.star.loader.SharedLibrary' is used. loaders: com.sun.star.loader.SharedLibrary | com.sun.star.loader.Java.
regmerge

Usage:

Regmerge is a small tool to merge different registry files under a specified key into another registry file. If a value already exists in the targetfile the value would be overwritten by the value of the sourcefile.

regmerge mergefile mergeKeyName regfile_1 ... regfile_n
regmerge @regcmds
regview

Usage:
Regview is a small tool to show the content of a registry file. The tool dumps the hierarchical structure and the values of the nodes to stdout in a human readable form.

regview registryfile [keyName]
xml2cmp

Usage:

The tool xml2cmp.exe parses .xml files, which contain the descriptions of components that implement UNO services. Each .xml file refers to one library. The library may contain one or more component descriptions.
There are two ways of using xml2cmp.exe:

  • xml2cmp [-func funcFile] [-html htmlFile] [-types typeFile] Xml_FileName
    This version parses the file <xml_filename> and produces three possible types of output, each of which is optional, but there must be at least one of them.

Options:

  • -func funcFile
    produces a file with the name <funcfile>. This should be .c / .cxx / .cpp or similar kind of source code file. This file contains the definition of the function const sal_Char * SAL_CALL component_getDescriptionFunc(); which returns the parsed file as ASCII text.
  • - html htmlFile
    produces a file with the name <htmlfile>. It should be a .htm / .html file. That file contains the contents of the parsed file in HTML-readable form.
  • -types typeFile
    produces a textfile with the name <typefile>. This textfile is intended to be included in a makefile and contains the definition of a variable
    <libraryname>
    <libraryName>_XML2CMPTYPES= <type_used_by_LibraryName_1> \
    <type_used_by_LibraryName_2> \
    ...

    So, the variable <libraryName>_XML2CMPTYPES contains a list of the types, used by that library.

All output of this first version of xml2cmp is put into the working directory.

  • xml2cmp -ix <sourcedirectory> <outputdirectory> [<tagname1> [ <tagname2> ...]]
    This version parses all .xml files which are found in <sourcedirectory> or its subdirectories. It produces the .html output of all parsed .xml files (as in version 1 above). Also, it produces a file, named xmlindex.html. This is an HTML file which contains tables alphabetically ordered on the left side, which allows assigning, from one XML-tags' contents to another (of all original parsed .xml files). The following tables are produced ("Module" refers to a library):

    SupportedService -> ModuleName
    ModuleName -> SupportedService
    <tagname1> -> ComponentName
    <tagname2> -> ComponentName
    ...

    All output files of the second version of xml2cmp are put to the <outputDirectory>.

 
uno.exe

Usage:

The UNO-starter is for running a component or service process, providing a runtime environment. Raising a component might look like this

[c:\] uno.exe -c MyComponent -l mycomp.dll -r myregistry.rdb -- foo bar

or

[c:\] uno.exe -s foo.bar.FooBarService -r myregistry.rdb -- foo bar

The starter loads the component and instantiates it. The component must export the interface com.sun.star.lang.XMain:

interface XMain : com::sun::star::uno::XInterface
{
    /** This method is called to run the component.
        <BR>
        @param aArguments command line arguments
        @return process error code to be returned to system
    */
    long run( [in] sequence< string > arguments );
};

Method run() will be called and returns the error code given, back to the system. If the uno starter is executed with the -u (URL) option, then XInitialization is used instead of XMain. The -u option is described later.

Command line parameters:

uno (-c ComponentImplementationName -l LocationUrl | -s ServiceName)
[-ro ReadOnlyRegistry1] [-ro ReadOnlyRegistry2] ... [-rw ReadWriteRegistry]
[-u uno:(socket[,host=HostName][,port=nnn]|pipe[,name=PipeName]);iiop|urp;Name
[--singleaccept] [--singleinstance]]
[-- Argument1 Argument2 ...]

You can either specify a component implementation name and a component location url (e.g., a shared library or jar file) or you specify the service name of a registered service.

  • ComponentImplementationName
    ComponentImplementationName is the implementation name of the component, e.g., MyFooServiceImpl.

  • LocationUrl
    LocationUrl is the file name of a shared library or jar file.

  • ServiceName
    You can also specify a ServiceName if your component is already registered. This looks for any registered component implementation in the registry.

  • Registries
    The optional Registries (e.g., c:\myreg.rdb) are used by the ServiceManager. The ro ones are opened for reading only; whereas, a single rw one will be opened for reading and writing. If the rw one does not exist, then it may be created. Components may read and write to store their persistent state.

The -u (URL) option provides the opportunity to accept incoming connections and distribute component instances to other processes. Clients resolve outer process objects using the com.sun.star.connection.UnoUrlResolver service with this url. The starter accepts incoming client connections of the clients' com.sun.star.connection.UrlResolver service and provides the desired instance.
Component instances started via -u are not run using the XMain interface, they are initialized via the XInitialization interface, given the command line params.

  • HostName
    Specifying a host name might be necessary to distinguish the network interface to be used, if a machine is part of two networks.

  • PipeName
    Name of a named pipe.

  • Name
    Identifier for called component instances.

  • --singleaccept
    The uno starter will accept one connection, provide the component instance and die.

  • --singleinstance
    The uno starter will accept any number of connections, but will provide the same single component instance any time instead of creating a new instance for each connection.

Service com.sun.star.bridge.UnoUrlResolver

You can easily connect to a server started with the -u (url) option by using this service giving the same url to resolve. The service provides you an instance from remote.
 

Author: Jürgen Schmidt ($Date: 2004/10/29 07:54:59 $)
Copyright 2001 Sun Microsystems, Inc., 901 San Antonio Road, Palo Alto, CA 94303 USA.

Apache Software Foundation

Copyright & License | Privacy | Contact Us | Donate | Thanks

Apache, OpenOffice, OpenOffice.org and the seagull logo are registered trademarks of The Apache Software Foundation. The Apache feather logo is a trademark of The Apache Software Foundation. Other names appearing on the site may be trademarks of their respective owners.