| Age | Commit message (Expand) | Author |
|---|
span>Add a FunctionBasedURPConnection and a websocket URP connector | Skyler Grey |
|
- 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>
|
|
Since ae855bf48163ff64d94cfc34aff8e37abdb5518d and
35518c92365cc183ba6cce2a4d284a130c0ca13f 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>
|
|
Add a java module named "org.libreoffice.unoloader" for this jar.
Require this module from org.libreoffice.uno
(libreoffice.jar has unoloader.jar in its classpath,
so add the same dependency to the modules)
Change-Id: I7471d65ac7a0d2c6a11c002027a21f0c441dd1f2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94419
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
|
|
Add a java module named "org.libreoffice.uno" for this jar.
This needs to be compiled with Java 9.
But since we want to keep b/c with Java 8,
the rest of the jar has to be compiled with Java 8.
This bumps the *build* requirement to Java 9 while keeping
the *runtime* requirement at Java 8.
The gbuild JavaClassSet class is changed to invoke javac twice,
where the 2nd invocation compiles with --release 9 and a --patch-modules
argument so that it finds the results of the first invocation and also
the javamaker generated files in CustomTargets.
Change-Id: I888f5dbe097cc37136e68db5919939877c981862
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91105
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 ae855bf48163ff64d94cfc34aff8e37abdb5518d
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>
|