The CliUnoApi_oootypes does not use the same version file as everything
else, so pass that in as a parameter.

perl cli_ure/source/scripts/increment_version.pl cli_ure/version/version.txt cli_ure/version/incversions.txt temp.txt && mv temp.txt cli_ure/version/version.txt

perl cli_ure/source/scripts/increment_version.pl unoil/climaker/version.txt unoil/climaker/incversions.txt temp.txt && mv temp.txt unoil/climaker/version.txt

Change-Id: Iaea028fc345d090317f7ebf128b683b4643a1093

There is a increment_version.pl, which uses the incversions.txt
to increment the CLI version numbers.

But it first checks that there are new published UNO types,
and exits if there are none. Not sure where the input for that
is supposed to come from.

But the OOo docs claim that all version numbers have to be
incresed for every release to work around some MSI issue,
so change the script to do that and add an incversion.txt
in unoil too.

http://www.openoffice.org/udk/common/man/spec/assemblyversioning.html
https://support.microsoft.com/en-us/help/905238/an-assembly-in-the-global-assembly-cache-or-sxs-is-missing-after-you-p

Change-Id: I6190b53d1a3ff00b9fe014f86f7ec8cddef9904e

Set up the toolchain to create sources and javadocs artifacts in
addition to JARs created during the build. Use Buck build tool for
that: [1]. This is a fork of Google's build tool Blaze, created by
Xooglers at Facebook. This build tool (like Blaze itself) uses
Python to write build files.

Add needed tools and build files to install LibreOffice API artifacts
to local Maven repository or deploy them to Maven Central.

To build all needed artifacts LibreOffice must be built regularly
with GNU make first. To build the rest of the API (sources and
javadocs):

  $> buck build api

To replace version number with upcoming release version:

  $> solenv/bin/version.py 5.1.0

To install the API to local Maven repository:

  $> buck build api_install

To deploy the API to Maven Central:

  $> buck build api_deploy

Detailed documentation is added to document the prerequisites and
the workflow to upload LibreOffice API to Maven Central.

* [1] https://buckbuild.com

Change-Id: Ibdd552a01110836703bc069abe829b9921491cac
Reviewed-on: https://gerrit.libreoffice.org/20343Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
Tested-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>

As outlined in the requirements to deploy the artifacts on Maven
Central, the metdata must be provided:

* Project Name, Description and URL
* License Information
* Developer Information
* SCM Information

[1] http://central.sonatype.org/pages/requirements.html

Change-Id: I0bcd19a22d0e1a48f0faec0b414f816f7da5b318
Reviewed-on: https://gerrit.libreoffice.org/20315Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>

Tweak the installer so it reads the included files from SRCDIR.

Change-Id: Ic4d3d2c003c2d0c5aebea6dd32f5989f3d4f04e4

Change-Id: I2bc45e4ba63f5faaee7389bcd9d7b3f563503186

Change-Id: I9f6a410515106941c4848edafaffaeacbc27b125

- gb_UnoApi_get_target returns the files in INSTDIR
- stop using rdb files from OUTDIR
- remove gb_UnoApi_install
- remove pointless 2nd parameter of gb_UnoApi_UnoApi
- order-only dependency from gb_UnoApi_get_target to
  gb_UnoApiHeadersTarget_get_target because INSTDIR .rdb is always outdated

Change-Id: Id418f75e9b38d6fe135b55eca2594c2624bc41cc

Change-Id: Ib451bdb3c1c2ca42347abfde44651d5cf5eef4f3

Change-Id: I55447aba5abcc8205543c7ca64763b5c99854837

...also, the use of double use of udkapi.rdb in climaker call in
testtools/CustomTarget_bridgetest_climaker.mk looked fishy.

Change-Id: I8be22b184740d65e567df65bae51fe18066be102

Make javamaker work on top of unoidl/ instead of registry/.

API CHANGE: javamaker no longer supports the -B switch, as that is meaningless
with the new format.  When reading from an old-format .rdb file, /UCR is hard-
coded as the prefix now.

Change-Id: I8cca39f8ebacd0476934f7bd493d206928d063a9

Change-Id: Icba4218c5f9fe89d183d25ea82a8eae52881f885

Change-Id: I54d8923ad315e8041fd3904da3a29f1a7a8c8b16

Change-Id: I49272003ea72c84c9e81bc826820b0ac5f9d5008

Let gb_JavaClassSet_use_customtarget add the customtarget workdir to the
classpath.

Change-Id: I836e890b43bb2ca06d19cf9f83a5fa8f735cf963

Variables should have module name as prefix to prevent collisions.

Change-Id: I0a3ad6553692fc21eaf96cf35e9c343b4d716c21

this removes dmake completely out of the build for migrated modules
build.pl now assumes modules to be gbuild, unless there is a
prj/dmake file

Change-Id: I674a036b182ee13c5ec093e83cb3d38133112d3b

Otherwise the class files for IDL files that were removed still end up
in unoil.jar and may cause JunitTest to fail with
"binaryurp::Unmarshal: type with unknown name: ".

This brings two changes:
- no more recursive calling of make
- gbuild_simple is now not used => removed

Naming convention for gbuild methods:
- "add" is used for stuff that is logically a part of the target
  (i.e. not registered at the Module, but defined in the target's makefile)
- "use" is used for stuff that is logically a different target
  (i.e. it is registered at the Module, has it's own makefile, may be
  in a different module than the target)

Where necessary, replace with wildcard, what does not change path.