ae855bf481
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> |
||
|---|---|---|
| .. | ||
| config | ||
| docs | ||
| examples | ||
| qa/checkapi | ||
| settings | ||
| source | ||
| util | ||
| build-examples_common.mk | ||
| CppunitTest_odk_checkapi.mk | ||
| CustomTarget_allheaders.mk | ||
| CustomTarget_build-examples.mk | ||
| CustomTarget_build-examples_java.mk | ||
| CustomTarget_check.mk | ||
| CustomTarget_classes.mk | ||
| CustomTarget_config_win.mk | ||
| CustomTarget_doxygen.mk | ||
| CustomTarget_html.mk | ||
| CustomTarget_javadoc.mk | ||
| CustomTarget_settings.mk | ||
| CustomTarget_unowinreg.mk | ||
| Executable_unoapploader.mk | ||
| GeneratedPackage_odk_doxygen.mk | ||
| GeneratedPackage_odk_javadoc.mk | ||
| GeneratedPackage_uno_loader_classes.mk | ||
| index.html | ||
| index_online.html | ||
| Library_unowinreg.mk | ||
| Makefile | ||
| Module_odk.mk | ||
| Package_cli.mk | ||
| Package_config.mk | ||
| Package_config_win.mk | ||
| Package_docs.mk | ||
| Package_examples.mk | ||
| Package_html.mk | ||
| Package_odk_headers.mk | ||
| Package_odk_headers_generated.mk | ||
| Package_settings.mk | ||
| Package_settings_generated.mk | ||
| Package_share_readme.mk | ||
| Package_share_readme_generated.mk | ||
| Package_unowinreg.mk | ||
| README | ||
Office development kit - implements the first step on the way to the LibreOffice SDK tarball.
Part of the SDK; to build you need to add --enable-odk.
Testing the examples:
=====================
* Go to instdir/sdk (Don't try directly in odk/)
* See <https://api.libreoffice.org/docs/install.html> how to set up the SDK.
** When asked about it during configuration, tell the SDK to do automatic
deployment of the example extensions that get built.
* In a shell set up for SDK development, build (calling "make") and test
(following the instructions given at the end of each "make" invocation) each
of the SDK's examples/ sub-directories.
** An example script to build (though not test) the various examples in batch
mode is
find examples \( -type d -name nativelib -prune \) -o \
\( -name Makefile -a -print -a \( -execdir make \; -o -quit \) \)
(Note that one of the example extensions asks you to accept an example
license on stdin during deployment.)