Remove the obsolete test code related to Java Applets in the bean module.
Since the Applet feature is being removed, these tests are no longer needed.
Change-Id: Iaee7aad618e6addff5f14c08ec4a07d920c01a90
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/195592
Reviewed-by: Stephan Bergmann <stephan.bergmann@collabora.com>
Tested-by: Jenkins
Previously, all of the README files have been renamed to README.md
and now, the contents of these files were changed to use Markdown
format. Other than format inconsistency, some README.md files lacked
information about modules, or were out of date. By using LibreOffice
/ OpenOffice wiki and other documentation websites, these files were
updated. Now every README.md file has a title, and some description.
The top-level README.md file is changed to add links to the modules.
The result of processing the Markdown format README.md files can be
seen at: https://docs.libreoffice.org/
Change-Id: Ic3b0c3c064a2498d6a435253b041df010cd7797a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113424
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
Renaming all README files for all top level modules to README.md,
applying no content change at this stage to be able to track history
of the files. These files should be edited to use correct Markdown
syntax later.
Change-Id: I542fa3f3d32072156f16eaad2211a397cc212665
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112977
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
Fix these kinds:
/home/pi/lo/libreoffice/bridges/source/cpp_uno/gcc3_linux_arm/uno2cpp.cxx:103:10: error:
externally available entity 'is_complex_struct' is not previously declared in an included file
(if it is only used in this translation unit, make it static; otherwise, provide a declaration of it in an included file) [loplugin:external]
bool is_complex_struct(const typelib_TypeDescription * type)
~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/pi/lo/libreoffice/bridges/source/cpp_uno/gcc3_linux_arm/uno2cpp.cxx:129:10: error:
externally available entity 'is_float_only_struct' is not previously declared in an included file
(if it is only used in this translation unit, make it static; otherwise, provide a declaration of it in an included file) [loplugin:external]
bool is_float_only_struct(const typelib_TypeDescription * type)
~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/pi/lo/libreoffice/bridges/source/cpp_uno/gcc3_linux_arm/uno2cpp.cxx:168:6: error:
externally available entity 'MapReturn' is not previously declared in an included file
(if it is only used in this translation unit, make it static; otherwise, provide a declaration of it in an included file) [loplugin:external]
void MapReturn(sal_uInt32 r0, sal_uInt32 r1, typelib_TypeDescriptionReference * pReturnType, sal_uInt32* pRegisterReturn)
/home/pi/lo/libreoffice/bridges/source/cpp_uno/gcc3_linux_arm/uno2cpp.cxx:446:32: error:
static_cast from 'void **' to 'sal_Int32 *' (aka 'long *') is not allowed
sal_Int32 * pTempIndices = static_cast<sal_Int32 *>(pCppArgs + nParams);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
or some of these:
In file included from
/home/pi/lo/libreoffice/bean/native/unix/com_sun_star_comp_beans_LocalOfficeWindow.c:26:
/usr/lib/jvm/java-11-openjdk-armhf/include/jni.h:1945:1: error: unknown
attribute 'externally_visible' ignored [-Werror,-Wunknown-attributes]
_JNI_IMPORT_OR_EXPORT_ jint JNICALL
^
/usr/lib/jvm/java-11-openjdk-armhf/include/jni.h:1943:32: note: expanded
from macro '_JNI_IMPORT_OR_EXPORT_'
define _JNI_IMPORT_OR_EXPORT_ JNIIMPORT
^
/usr/lib/jvm/java-11-openjdk-armhf/include/linux/jni_md.h:35:42: note:
expanded from macro 'JNIIMPORT'
define JNIIMPORT
__attribute__((externally_visible,visibility("default")))
Change-Id: I7cae1c52ee10306da666c9c234b9af7248efd04e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108567
Tested-by: Julien Nabet <serval2412@yahoo.fr>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Since ae855bf481 and
35518c9236 the ridl,jurt und unoil jars
were merged into libreoffice.jar. Adapt the buck build correspondingly.
Preserve the publishing of merged jars for now with dummy content and
consider to remove them in future releases.
Test Plan:
1. To replace version number with upcoming release version:
$ solenv/bin/version.py 7.1.0
2. To install the API to local Maven repository:
$ VERBOSE=1 buck build api_install
3. To deploy the API to Maven Central:
$ VERBOSE=1 buck build api_deploy
Change-Id: Id1b2135682ab962c901b944f3c26aeead9a4b19b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93724
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
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>
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>
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>
Andrea Gelmini