- FunctionBasedURPConnection is used to enable a client to open a URP
connection to a fresh Kit instance in COOL.
- This URP connector can be used with that and
https://github.com/CollaboraOnline/online/pull/6992 to use a Java Uno
Remote Protocol client over websockets
- For interoperability with existing Collabora Online websockets a
prefix (urp ) is added to each message sent and a similar prefix
(urp: ) is expected on each message recieved. This allows sending over
the same websocket as other data is being transmitted through. If you
are writing a bridge to work with this, you will need to add/strip the
prefixes accordingly
- This commit uses Java WebSocket
(https://github.com/TooTallNate/Java-WebSocket) to send data over
websockets.
Change-Id: I2bda3d0b988bef7883f9b6829eeb5b7ae8075f27
Signed-off-by: Skyler Grey <skyler.grey@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151171
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
This reverts commit 64469bb1a7.
To keep the compatibility with C++98, we need to revert the previous patch.
Quoting sberg:
"This code happens to not normally be processed (see ure/source/uretest/README)
and is meant to be compilable with the 3rd-party UNO compiler baselines (i.e.,
just C++98, which implies no range base for loops)."
Change-Id: I1355a29af24299a99a23dfcd1dd473894d7c9e0c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142302
Tested-by: Jenkins
Reviewed-by: Hossein <hossein@libreoffice.org>
...which were used by ildc, which is gone since
a8485d558f "[API CHANGE] Remove deprecated idlc
and regmerge from the SDK", and have always been ignored as legacy by its
unoidl-write replacement.
This change has been carried out (making use of GNU sed extensions) with
> for i in $(git ls-files \*.idl); do sed -i -z -E -e 's/\n\n((#[^\n]*\n)+\n)*(#[^\n]*\n)+\n?/\n\n/g' -e 's/\n(#[^\n]*\n)+/\n/g' "$i"; done && git checkout extensions/source/activex/so_activex.idl odk/examples/OLE/activex/so_activex.idl
which apparently happened to do the work. (The final two files are not UNOIDL
source files.)
Change-Id: Ic9369e05d46e8f7e8a304ab01740b171b92335cd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135683
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
* Client code must replace uses of idlc and regmerge with uses of unoidl-write,
see the changes to odk/examples/ and ure/source/uretext/ in
40f2aee658 "Provide unoidl-write also for the
SDK" for examples.
* The new types.rdb format is not compatible with LibreOffice < 4.1. Clients
generating extensions containing such files are advised to use appropriate
LibreOffice-minimal-version elements.
* For compatibility with old extensions, reading the legacy types.rdb format is
still supported.
* The SDK no longer ships an idl/ sub-directory containing the udkap and offapi
.idl files (as, unlike idlc, unoidl-write does not need them).
odk/config/cfgWin.js had to be adapted to look (somewhat arbitrarily) for an
examples/ sub-directory instead of idl/ when checking for "an sdk folder".
gb_UnoApi_package_idlfiles became unused and has been removed.
* The idlc and regmerge executables have been removed. Module idlc has been
removed except for idlc/test/parser/, which is also used by
CustomTarget_unoidl/unoidl-write_test, and which may eventually be moved into
module unoidl. Module external/ucpp and the corresponding configure options
have also been removed.
Change-Id: I42a0231699b863b5ebe2bee63bc32c8f79278cc1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122363
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...after the new types.rdb format that unoidl-write generates has been used
internally since LibreOffice 4.1 in 2013; following up on
6db34b6b33 "Directly build UNOIDL .rdb files from
.idl files" and its "The legacy tools idlc, regcompare, regmerge, and regview
are still contained in the URE or SDK for now."
The tools idlc and regmerge are deprecated but still shipped in the SDK for now.
The plan is to drop them completely for LO 7.5.
odk/examples/ and ure/source/uretest/ are adapted to use unoidl-write instead of
idlc and regmerge:
* unoidl-write does not use a C preprocessor and the # directives in .idl files,
it supports reading a single .idl file (containing an arbitrary number of
declarations) or a directory tree where each directory corresponds to a UNOIDL
module of the same name and each .idl file contains the declaration of the
(non-module) UNOIDL entity of the same name. For some of the odk/examples/,
that required moving individual .idl files into sub-directories named after
the respective modules. In odk/settings/std.mk, definitinos of IDL and
REGMERGE have been replaced with a new UNOIDLWRITE.
* unoidl-write always enforces reserved UNOIDL identifier restrictions (see
04af4e4f55 "[API CHANGE] Fix all bad UNOIDL
identifiers across offapi" and 6201792406
"Enforce the UNOIDL identifier scheme") (which idlc only enforced optionally
with -cid -we). That required renaming "my_module" in
odk/examples/DevelopersGuide/Components/CppComponent/.
* The new types.rdb format is not compatibly with LibreOffice < 4.1. Clients
generating extensions containing such files are advised to use appropriate
LibreOffice-minimal-version elements.
Change-Id: I1a248fd96e86ecbf407f829bc100d44bfe7f4e7d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130533
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
... move it into cpputools and rename ure/Package_install.mk to
ure/Package_ure_install.mk, to match the module name.
Follow up from commit 92a90cf5cc
("Don't build the static uno binary"). I missed that hunk in a
larger patch, because the script was in a different module, then
the binary.
Change-Id: If7f3152be9567cf84be176d3fedefbcd5ad8d387
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128138
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
...instead of by listing the content somewhat redundantly in the Rdb_*.mk
files, to avoid duplication of logic for components that are only built
conditionally (and thus should only be included conditionally in the
corresponding Rdb). To achieve that, add an "rdb" parameter to
gb_ComponentTarget_ComponentTarget (and to the gb_*_set_componentfile macros
that internally call gb_ComponentTarget_ComponentTarget), which is used to make
the appropriate gb_Rdb_add_component call internally from within
gb_ComponentTarget_ComponentTarget. (As a special case,
gb_CppunitTest_set_componentfile shall not call gb_Rdb_add_component, as that
has already been done by the corresponding gb_Library_set_componentfile call, so
allow the gb_ComponentTarget_ComponentTarget "rdb" parameter to be empty to
support that special case.)
Most Rdb_*.mk files are thus mostly empty now. One exception is
i18npool/Rdb_saxparser.mk, which duplicates some of the Rdb_services content as
needed during the build in CustomTarget_i18npool/localedata.
1c9a40299d "gbuild: create services.rdb from built
components" had already tried to do something similar (in addition to other
things) under a new --enable-services-rdb-from-build option. However, that
approach had four drawbacks that this approach here addresses (and which thus
partly reverts 1c9a40299d):
1 Rdb_services shall not contain the component files of all libraries that are
built. While that commit filtered out the component files that go into
Rdb_ure/services (ure/Rdb_ure.mk), it failed to filter out the component files
that go into others like Rdb_postgresql-sdbc
(connectivity/Rdb_postgresql-sdbc.mk).
2 The code added by that commit to Makefile.gbuild codified the knowledge that
there is an Rdb_services, which is brittle.
3 The code added by that commit to solenv/gbuild/Rdb.mk codified the knowledge
(for gb_Rdb__URECOMPONENTS) that there is an Rdb_ure/services, which is brittle.
4 Introducing an --enable-services-rdb-from-build option needlessly provided
two different ways how the content of Rdb_services is assembled.
The changes done here would leave --enable-services-rdb-from-build as a
misnomer, as it no longer controls how Rdb_services is assembled. I thus
renamed it to --enable-customtarget-components, as that is apparently what it
still does now.
Change-Id: Ia5e8df4b640146c77421fcec6daa11a9cd260265
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126577
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...which considers an argument containing SEPARATOR characters only as a
relative URL (which it then makes absolute relative to osl_getProcessWorkingDir)
if it starts with a dot (see convertToFileUrl in
codemaker/source/codemaker/global.cxx). (Which isn't an issue for now, as
convertToFileUrl leaves the relative path unchanged, which is passed to the
unoidl::detail::LegacyProvider ctor in unoidl/source/legacyprovider.cxx and on
to store::FileHandle::initialize in store/source/lockbyte.cxx, which makes a
relative pFilename absolute relative to osl_getProcessWorkingDir. But it would
become an issue when the given type RDBs are changed to the new UNOIDL binary
format, as the unoidl::detail::UnoidlProvider ctor in
unoidl/source/unoidlprovider.hxx expects an absolute file URL.)
Change-Id: If9f66f3e9c20a8416d25989099e6c921520e6a94
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121312
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
* Updated README.md contents to fix various issues
* Fixed source links by using [git:], processed by mkdocs scripts
* Added README.md for ios, setup_native, unotest
* Fixed issues with "underline" and "less than" sign
Change-Id: I3e52a1d3372586c390ee6c42a2ef48bbabc81398
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114248
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
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>
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>
...that are no longer needed now that the dynamic exception specifications are
gone from C++ UNO, so won't cause std::unexpected any more.
Change-Id: Ie3418658f5a84e6cec1ac48e3413f523f87497fe
Reviewed-on: https://gerrit.libreoffice.org/52641
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
* GCC documents -fvisibility at least as far back as the GCC 4.0 online
documentation at
<https://gcc.gnu.org/onlinedocs/gcc-4.0.4/gcc/Code-Gen-Options.html>.
* For external code, odk/settings/settings.mk unconditionally set
HAVE_GCC_VISIBILITY_FEATURE for all platforms other than Windows.
Make this a fatal configure error for now. The check should be removed
completely after LO 5.3 branch-off.
Change-Id: I1de415b6ed1591e0a7b6640ece861b6f0ef74112
Reviewed-on: https://gerrit.libreoffice.org/29073
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-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
...unused since 0c1dc375b4 "Make
ure/source/uretest/ use defaultBootstrap_InitialComponentContext"
Change-Id: I42385d2d92fb1e24376829ce5c7ae112ea771e51
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
...which was effectively unused; there only ever was a single sunjavaplugin that
is now folded directly into jvmfwk. Leaves room for further clean up.
Change-Id: I14dd2a3a09bd1ce9a8c3f5c156628ec11d954a0b
So no need to expand it at configure time in ure/source/unorc, and no need to
handle the related builddir!=srcdir complications.
Change-Id: Ifa34d25fab9ad2da13ed039bf6c5921b0fb58703
...like is done for most other ini-files too, with entries indentical to the
ones in scp2/source/ooo/ure.scp. (And sort ini-files lexicographically again in
instsetoo_native/*.mk, broken with recent louno rename).
Leave ure/source/unorc.in and ure/Pacakge_builddir_install.mk around for the
cross-compilation case only.
Change-Id: Ic07e036ef126db1aee2c0f6b726c2b86c2536c53
In other words, only executable files go in the MacOS folder. Dynamic
libraries and bundled frameworks (i.e., LibreOfficePython), and
nothing else, go in the Frameworks folder, and all other files go in
the Resources folder.
Especially, note that Java class files and rc (.ini) files also go in
Resources.
Such an app bundle structure is what Apple strongly suggests one
should use, and it has been hinted that future versions of code
signing and/or Gatekeeper will require such a structure.
There is still some ugliness thanks to traces of the historical
separation of URE from "the office". Like there are two separate
"unorc" files, one for URE, one for the LibreOffice application. IMHO,
this should be cleaned up, but is probably controversial.
(Eek! I now see there are actually *three* unorc files in the app
bundle. Not intentional. Need to fix that later.)
Change-Id: Idcf235038deb5b8e1d061734993e9f31869b7606
The problem is that the ure/source/unorc file is now expanded by the configure
script, and thus exists only in builddir. But a further complication is that
the uno.ini file is in srcdir. This is one way to handle it. Seems to work for
me, let's see what the srcdir!=builddir tinderbox slaves say.
Change-Id: I6fb456cf849ce5077e2c5bd25dc9149096aab241
Muhammad Naeem