| Age | Commit message (Collapse) | Author |
|---|
|
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>
|
|
...assuming the delayLoadHook in cli_ure/source/native/native_bootstrap.cxx is
no longer necessary and loading of cppuhelper from the program dir cannot fail
regardless in whatever scenario the cli_cppuhelper library itself is loaded.
Change-Id: I13f32b327bca4cce9780864f5e57cdad3860afe5
|
|
Change-Id: I86864f832c0377d307cfa0b2c137f452e43797eb
|
|
The ../../../program/ links in the URE jar Class-Paths are a temporary kludge
(and juh.jar had lacked adaption for Mac OS X).
Change-Id: I2542d8a582866485dd61c05df3fc6b4b39a8403d
|
|
It had originally been used in the SDK's "Simple Bootstrap" for Java,
com.sun.star.lib.loader.Loader class, but only left in there for backwards
compatibility with pre--three-layer OOo versions (i.e., < OOo 3) when that
Loader was switched to use the unoinfo executable with the fix for #i88687#
"C++/Java Simple Bootstrap broken" in e2b7ea631a5e7297346ec826527a019e2baca020
"INTEGRATION: CWS sb87 (1.5.10); FILE MERGED: 2008/05/07 11:34:25 sb
1.5.10.1: #i88687# let Loader call new unoinfo instead of old juh.jar
UnoInfo.getJars."
Recent work in AOO to undo three-layer caused AOO to now accidentally use the
backwards-compatibility code, so AOO ran into a problem that they solved with a
change to com.sun.star.comp.helper.UnoInfo that LO erroneously merged in as
95ada2d65f6d999920f2a04599ac132fa632d66d "Related: #i122483# set correct
classpath, include unoil.jar."
The better approach is to get rid of that backwards-compatibility code and
remove the obsolete UnoInfo class. While this is nominally incompatible, in
practice no other client code but the SDK's com.sun.star.lib.loader.Loader
should ever have used it (it should have been designed as a private interface
for just that one client from the start, anyway). Java applications using
"Simple Bootstrap" and built against old versions of the SDK (post the fix
for #i88687# and its introduction of the unoinfo exectuable in OOo 3) will
continue to work against new LO versions (as the backwards-compatibility code
that would call the removed UnoInfo class will not be triggered anyway; and even
if it were, all resulting exceptions would be caught and the new code path using
the unoinfo executable be chosen then). Likewise, Java applications using
"Simple Bootstrap" and built against the new SDK will continue to work against
old OOo/LO/AOO vesions as far back as the fix for #i88687# and its introduction
of the unoinfo exectuable in OOo 3.
Change-Id: I64824ed002c3ccdf6912eab67499beb0c423081e
|
|
...into a new smoketest.jar, so that URE juh.jar no longer depends on non-URE
unoil.jar.
Change-Id: I8937c78d8af6e2f82ada5dd80c322f8bca5ec2f5
|
|
|
|
Change-Id: I54d8923ad315e8041fd3904da3a29f1a7a8c8b16
|
|
... com.sun.star.comp.helper.RegistryServiceFactory (juh.jar). Superseded by
default bootstrap mechanisms.
An aborting stub for non-inline cppu::createRegistryServiceFactory is left in
cppuhelper/srouce/compat.cxx to avoid having to incompatibly change
cppuhelper/soruce/gcc3.map.
Change-Id: I590e50b8f57e86d4bb3e00d157c9e5907c02f267
|
|
Change-Id: I9f49970e5e06d1afd3fc066a20d1671c93e262fc
|
|
With gb_Jar_add_jar and gb_Jar_add_system_jar adding to the manifest
classpath automatically it is no longer necessary to call
gb_Jar_set_jarclasspath manually except for the URE jars, which
are apparently not supposed to be added automatically.
Change-Id: I1e743e7ecb9cb5651e02005aa09e127bea1b0a29
|
|
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)
|
|
|
|
|
