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>
in the absence of any other constructors, the compiler will automatically
generate a public no-arg constructor
Change-Id: I70eca507cd8e16e33580b3398d41d70690bc2909
* Re-use existing settings/dk.mk to tunnel ENABLE_DEBUG into the SDK. Turns out
this was explicitly included in ~all examples Makefiles, but only after
settings.mk where it is now used, so include it in settings.mk now and dropped
it from all the exmaples Makefiles.
* The old settings.mk was apparently confused with using /MT ("link with
LIBCMT.LIB") on cl command line and /MD ("link with MSVCRT.LIB") on link
command line (where it was ignored), and you apparently can't pass both
together to cl, so I settled on /MD (resp. /MDd) now and dropped /MT (resp.
/MTd). No idea if that is exactly right, however.
* Introduced client-facing LIBO_SDK_LDFLAGS_STDLIBS that covers kernel32.lib and
msvcrt.lib vs. msvcrtd.lib on Windows. Adapted examples Makefiles and
/ure/source/uretest/Makefile accordingly. Some examples Makefiles
additionally use msvcprt.lib, no idea whether that still needs to be
addressed.
Change-Id: Ia8d9d177e415abfbaf6f9fa6239f0ef9998868be
Samuel Mehrbrodt