This moves the classes from juh.jar and ridl.jar to libreoffice.jar
The goal is to have one single jar (and Java module, will be added later)
which developers can include to work with LO.
juh.jar and ridl.jar are kept as basically empty jars with libreoffice.jar
on its classpath to keep backwards compatibility.
This is a continuation of ae855bf481
and a preparation to have Java 9 module support.
Change-Id: Ifbbfb97f60373d14256e62ae3122913bd17d5bbb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91930
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
jurt.jar and unoil.jar are kept as effectively empty jars, each with a
Class-Path: ridl.jar
in their meta-inf/manifest.mf, so that 3rd-party code loading them (with or
without also loading ridl.jar) will still have access to their content.
Conceptually, the UNOIDL entities in unoil.jar (corresponding to module offapi)
are not part of the URE, but are now made available by URE's ridl.jar. This
should probably not cause problems in practice.
At least for now, we seal exactly those packages in ridl.jar that were
originally sealed in jurt.jar. Ideally, all of ridl.jar could be sealed now,
but that would be mildly incompatible, as it would prevent 3rd-party code from
introducing additional UNOIDL entities in the relevant namespaces (even if that
is something we do not want 3rd-party code to do anyway).
However, some JunitTest_jurt_* define classes in those sealed packages. In the
past they got away with that by using gb_JunitTest_use_jar_classset,*,jurt.
Instead they now need to gb_JunitTest_use_jar_classset,*,ridl and drop the
gb_JunitTest_use_jar,*,ridl. But the former only makes available the classes
that are specified in ridljar/Jar_ridl.mk with gb_Jar_add_sourcefiles, not the
UNOIDL entities specified via gb_Jar_add_packagedirs. But the tests need the
udkapi UNOIDL entities, so introduce gb_JunitTest_add_classpath to let the tests
get them explicitly. (Curiously, JunitTest_jurt_uno and JnitTest_jurt_util use
gb_JunitTest_use_jar_classset,*,jurt but don't seem to acutally need it; lets
leave that for a follow-up clean up.)
As a follow-up clean up, relevant files could be moved from jurt/ to ridljar/.
Change-Id: I836f4e7bb47fb41f1306e3f223da90dba988eb9a
Co-authored-by: Stephan Bergmann <sbergman@redhat.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/84946
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Without this patch, warnings will be given
when LibreOffice is built with JDK9 or later.
Change-Id: I7aa6e99ace2377fbdb7dd732949ce10d9bd9df58
Reviewed-on: https://gerrit.libreoffice.org/72947
Tested-by: Jenkins
Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
not before vowels with a consonant sound so its a url not an url
Change-Id: Ic27ff3bee67469284d460c31ced6f63cb3633db2
Reviewed-on: https://gerrit.libreoffice.org/72062
Reviewed-by: Jens Carl <j.carl43@gmx.de>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
We should only use generic foo function name when it takes params
that are also dependent on UNICODE define, like
LoadCursor( nullptr, IDC_ARROW )
where IDC_ARROW is defined in MSVC headers synchronised with
LoadCursor definition.
We should always use Unicode API for any file paths operations,
because otherwise we will get "?" for any character in path that
is not in current non-unicode codepage, which will result in failed
file operations.
Change-Id: I3a7f453ca0f893002d8a9764318919709fd8b633
Reviewed-on: https://gerrit.libreoffice.org/42935
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Uwinapi is discontinued.
Change-Id: I063b4d0d8fab2d60de168e960a63b8181158ac01
Reviewed-on: https://gerrit.libreoffice.org/23198
Reviewed-by: David Ostrovsky <david@ostrovsky.org>
Tested-by: David Ostrovsky <david@ostrovsky.org>
This reverts commit db57823374, as it causes
loplugin:externandnotdefined under clang-cl, and cross-compiling Windows on
Linux seems a rather dead project for now.
Change-Id: Ia7fd742385fa0d609007f70e5116a99729224f77
Reviewed-on: https://gerrit.libreoffice.org/29835
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Don't do it for the MSVC libraries though, e.g. on my system loading
msvcr70 fails, but the SDK example works without problems.
Change-Id: I81bc0b64967e7abb74ca1fff7a2e4b4dbd75d5a5
Reviewed-on: https://gerrit.libreoffice.org/24432
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
Regression from 26b4f5be81 (java:use
System.arrayCopy to copy arrays, 2015-06-09), as the old code used to handle
the case when aArguments was null.
How to reproduce:
1) Source the SDK environment.
2) cd instdir/sdk/examples/DevelopersGuide/OfficeBean/
3) make OOoBeanViewer.run
4) Click new document... -> Text Document -> NullPointerException
Change-Id: I5521c7fd200f6c74c5f2665f2e4a99f0d6abfeeb
Reviewed-on: https://gerrit.libreoffice.org/24366
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
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/20343
Reviewed-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/20315
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
and
coverity#1326732 Dm: Dubious method used
coverity#1326734 Dm: Dubious method used
coverity#1326735 Dm: Dubious method used
coverity#1326739 Dm: Dubious method used
Change-Id: Id9d39decf7442b503079ebcfe8c881f0f2fe3eb3
