'unopkg' is a tool for easy deployment of UNO packages in an existing office installation. UNO packages are UNO components (single libraries or Jar files or more complex zip files that contains one or more libraries| Jar files, type libraries and configuration items), scripts and [PRODUCTNAME] Basic libraries as zip package. 'unopkg' is not part of the SDK but comes with the office directly and is a development tool as well as an end user tool to deploy extension into an office installation.

More details concerning deployment and this tool can be find in the Developer's Guide: 4.9.1 UNO Package Installation Using unopkg.

Note: This tool works only in the <office>/program directory!

Usage:

unopkg add <options> package-path...
unopkg remove <options> package-name...
unopkg list <options> package-name...
unopkg reinstall <options>
unopkg gui
unopkg -V
unopkg -h


Sub-commands:

add	add packages
remove	remove packages by name
reinstall	export feature: reinstall all deployed packages
list	list information about deployed packages
gui	raise Package Manager Graphical User Interface (GUI)

Options:

-h, --help	show this help on the command line
-V, --version	shows version information
-v, --verbose	dump verbose output to stdout
-f, --force	force overwriting existing packages
--log-file <file>	custom log file; default: <cache-dir>/log.txt.
--shared	expert feature: operate on shared installation deployment context; run only when no concurrent Office process(es) are running!
--deployment-context <context>	expert feature: explicit deployment context

'pkgchk' is deprecated and you should use the new 'unopkg' deployment tool.

'pkgchk' is a tool for easy deployment of UNO packages in an existing office installation. UNO packages are UNO components (single libraries or Jar files or more complex zip files that contains one or more libraries|Jar files, type libraries and configuration items) and [PRODUCTNAME] Basic libraries as zip package. More detailed information concerning deplyoment can be find in the Developer's Guide: 4.9 Deployment Options for Components.

Note: This tool works only in the <office>/program directory!

Usage:

pkgchk <options> [package1 package2 ... ]

Options:

-s, --shared|revoke	check/install shared components; default: user
-r, --renewal	re-install all packages (useful for cache inconsistencies).
-f, --force-overwrite	force overwrite existing packages when copying from command line.
-v, --verbose	verbose output to stdout.
-l, --log <file>	custom log file; default: <cache>/log.txt.
--strict_error_handling	break process immediately if errors occur.
--supersede_basic_libs	overwrite existing basic library entries of same name.
--check_unorc_only	check/patch only the unorc (Unix), uni.ini (Windows).
--no_unorc_patch	don't touch unorc (Unix), uni.ini (Windows).
-h, --help	print a command line help to stdout.

The UNO-starter is for running a component or service process, and 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.
       
        @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.

Usage:

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 ...>]

Options:

<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 demanded called component instances.
<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.
--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.

'idlc' is the UNOIDL compiler. It is a full featured compiler used to check UNODL type definitions and transform valid type definitions into a binary type library format, which is later used by all codemaker tools. It is also used as a dynamic type library for UNO at runtime.
You can find a syntax description for UNOIDL here.

Usage:

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 included files that will be searched by the preprocessor are located. Multiple directories can be combined with ';'.
-D<name>	name defines a macro for the preprocessor.
-C	generates complete type information, including additional service information and documentation.
-h|?	print this help message and exit.

The 'cppumaker' generates a C++ representation for idl types. The cppumaker works on a typelibrary, which is generated by the UNOIDL compiler ( idlc). It generates the output for all specified types and for all types the specified types depend on.

Usage:

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> |-T<t1>;<t2>...	name specifies a type or a list of types. The output for this type and all dependent types are generated. If no '-T' option is specified, then output for all types is generated. It is also possible to use a wildcard 'xy.*' to generate a complete module inclusive all subdirectories. The use of '-T*' is equivalent to no '-T' option. Example: 'com.sun.star.uno.XInterface' or 'com.sun.star.uno.*' are valid types.
-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: 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) -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!! -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)
-G	generate only target files which do not exist.
-Gc	generate only target files whose content will be changed.
-X<name>	extra types which will not be taken into account for generation.

The 'javamaker' generates the appropriate Java class file for each idl type. The javamaker works on a typelibrary which is generated by the UNOIDL compiler ( idlc). It generates the output for all specified types and for all types the specified types depend on.

Usage:

javamaker [-options] file_1 ... file_n -Xfile_n+1 -Xfile_n+2

Options:

-O<path>	path describes the root directory for the generated output. The output directory tree is generated under this directory.
-T<name>|-T<t1>;<t2>...	name specifies a type or a list of types. The output for this type and all dependent types are generated. If no '-T' option is specified, then output for all types is generated. It is also possible to use a wildcard 'xy.*' to generate a complete module inclusive all subdirectories. The use of '-T*' is equivalent to no '-T' option. Example: 'com.sun.star.uno.XInterface' or 'com.sun.star.uno.*' are valid types.
-B<name>	name specifies the base node. All types are searched under this node. Default is the root '/' of the registry files.
-nD	no dependent types are generated.
-G	generate only target files which does not exists.
-Gc	generate only target files which content will be changed.
-X<name>	extra types which will not be taken into account for generation.

The rdbmaker generates subsets of the typelibrary. It generates a subset of the typelibrary, which contains all specified types and all types the specified types depend on. This can be used to provide all and only necessary types for a component.

The rdbmaker supports 2 modes:

1. using the internal UNO type description manager -> use -R<regname>
   where regname specifies the type library used by the UNO type description manager after UNO is bootstrapped. This option disables the use of any other type libraries.
2. using one or more type library files -> use file_1 ... file_n
   file_1 .. file_n specifies one or more valid type library files which are used to find the needed type information. The used type libraries have to support the same base node (-B option).

Usage:

rdbmaker [-options] (-R<regname> | 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> |-T<t1>;<t2>...	name specifies a type or a list of types. The output for this type is generated.Example: 'com.sun.star.uno.XInterface' is a valid type.
-FT<name> |-T<t1>;<t2>...	name specifies a type or a list of types. For this 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. This option takes effect using run mode 2 only.
-b<name>	name specifies the base node of the output registry. All types will be generated under this node. Default is the root '/' of the registry file.

'regcomp' is a tool to register|revoke external UNO components into|from a registry which is used in a UNO environment.

Usage:

regcomp -revoke [-br<registryfile>] -r <registryfile> -c <locationUrl>[-l<componentLoaderName>]

Options:

-register|revoke	register means that the components will be installed and revoke means that they will be removed.
-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, '-r' 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 a component (DLL, Class name, or an url of a jar file) or a list of urls separated by ';'s. Note that, if a list of urls is specified, the components must all need the same loader.
-l<componentLoaderName>	the name of the needed loader, if no loader is specified the 'com.sun.star.loader.SharedLibrary' is used. Supported loaders: 'com.sun.star.loader.SharedLibrary' | 'com.sun.star.loader.Java'.

'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 target file the value is overwritten by the value of the source file.

Usage:

regmerge [-v|--verbose] <mergefile> <mergeKeyName> <regfile_1> ... <regfile_n>

Options:

-v|--verbose	verbose output on stdout.
<mergefile>	specifies the merged registry file. If this file doesn't exists, it is created.
<mergeKeyName>	specifies the merge key, everything is merged under this key. If this key doesn't exists, it is created.
<regfile_1> ... <regfile_n>	specifies one or more registry files which are merged.

'regview' is a tool to show the contents of a registry file. The tool dumps the hierarchical structure and the values of the nodes in a human readable manner to stdout.

Usage:

regview <registryfile> [<keyName>]

Options:

-br<registryfile>	the name of the registry whose contents should be viewed.
<keyName>	the name of a registry key. The name must be fully qualified; for example, '/' means the root key and '/UCR/com/sun/star/uno/XInterface' shows the type specification of the XInterface type. If no key is specified, the tool dumps the whole content of the registry file.

The 'xml2cmp' tool 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:

Usage:

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>_XML2CMPTYPES= \ <type_used_by_LibraryName_1> \ <type_used_by_LibraryName_2> \ ... 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 that 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' content 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>

The 'autodoc' tool is used for creating javadoc-like documentation from C++ and UNOIDL source code.

There are some conventions to follow when documenting C++- or UNOIDL-sourcecode. See also the UNOIDL Documentation Guidelines.
If you are not familiar with these, but do know javadoc: For simple C++ sourcecode documentation, using javadoc-style comments will work.

Usage:

autodoc [ -v <VerboseNr> ] [ -name "<TitleForTheDocu>" ] -html <OutputDirectory> -lg <SourcecodeLanguage>
{ [ -p <ProjectName> <ProjectRootDirectory> ]  -t <SourceTree>* | -d <SourceDirectory>* | -f <SourceFile>* }*

Options:

-v <VerboseNr>	<VerboseNr> == 5 displays the parsed source code tokens, so you can locate which piece caused an parsing error. <VerboseNr> == 2 displays not only the parsed source code, but also the comments. This option must be the first one, if it is used.
-name "<Title>"	<Title> occurs as the title of the start page of the HTML output. If this option is omitted, a default title is created.
-html <OutputDirectory>	specifies the root directory where the HTML output is created. Autodoc does not remove old files there, though it overwrites them.
-lg <SourcecodeLanguage>	Possible values are: c++ | idl. This also specifies which files will be parsed: "c++" parses all files with the endings .hxx and .h, "idl" parses all files with the ending '.idl' . To change this behaviour, see at option -f.
-p <ProjectName> <ProjectDirectory>	this option can be used to divide large code bases into different projects. <ProjectName> gives a user-defined name for the project. <ProjectDirectory> is the root to which all paths, given with the following options -t,-d and -f, are relative. This option can be omitted when there are no projects and all paths in the following options are relative to the working directory. The "{ ... }*" around the options -p,-t,-d,-f indicates, that this whole block of options can be repeated, each block starting with a new -p.
-t <SourceTree>	specifies that all files in the directory <SourceTree> and it's subdirectories are parsed, where the file ending matches the option -lg. There can be given multiple directories after one -t option. All relative paths  are relative to the project-rootdirectory, given with the -p option.
-d <SourceDirectory>	Specifies that all files in th directory <SourceDirectory>, but NOT it's subdirectories, are parsed, where the file ending matches the option -lg. There can be multiple directories given after one -d option. All relative paths  are relative to the project-rootdirectory, given with the -p option.
-f <SourceFile>	parses the given file. The ending does not have to match the -lg option. There can be multiple files given after one -f option. All relative paths  are relative to the project-rootdirectory, given with the -p option.