The unpublished UNO enum
com::sun::star::drawing::framework::AnchorBindingMode
is only used inside sd and not relevant for any other UNO API.
Make it sd-internal, by removing the idl file and instead
defining an sd::framework::AnchorBindingMode enum class
in an sd-internal header.
Change-Id: Ic8b58d5eca0cb4f59f695630d15c2f361d2def4b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/209358
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
If there are multiple Java URP bridges that get disposed simultaneously, there
was a race in that one JobQueue could receive first its own dispose(), save that
disposeId as _doDispose, then receive an unrelated dispose() and overwrite its
_doDispose with that other disposeId, and only then get to the check of
_doDispose == _disposeId in removeJob(), which would thus never succeed and
cause the thread to hang in that loop forever.
So leverage the fact that the _disposeId, instead of being just an opaque token,
actually is the JavaThreadPool that initiated the disposing, so can be used to
check whether a JobQueue got disposed. (And rename some entities to make their
meaning more obvious.)
(Which then required reworking parts of the test code that checks the internals
of the Java URP bridge.)
Change-Id: If7f4f494b0f7e7f17e0a5c6a458582ad9bed3054
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/187476
Reviewed-by: Stephan Bergmann <stephan.bergmann@collabora.com>
Tested-by: Jenkins
…by a simple/static $(gb_CustomTarget_workdir)/foo
The build system has a lot of overly complicated leftovers from when it
was introduced and had not only deal with split repositories but also
had to coexist with another buildsystem. Along with lots of copy'n'paste
along the years the makefiles became hard to grasp for newcomers with
all our calls and evals.
As a first step to streamline that, the macros from TargetLocations that
simply prefix a static path to the argument (and similar of the same
kind) are a natural pick before simplifying the rules themselves/getting
rid of a bunch of eval statements.
Change-Id: Ia06dbbcd5d1994755a2ff05b84f72ccbc4e3cab5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167005
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
Testing a field which is being modified inside a synchronized block,
outside of such a block, is going to lead to weird ordering issues when
running a highly parallel test like this, so test the flag inside a
synchronized block.
Failure manifested as:
JUnit version 4.13.2
........E...........
Time: 17,27
There was 1 failure:
1)
testStaticThreadExecutesAsyncs(com.sun.star.lib.uno.environments.remote.JobQueue_Test)
java.lang.AssertionError: expected:<35> but was:<34>
at org.junit.Assert.fail(Assert.java:89)
at org.junit.Assert.failNotEquals(Assert.java:835)
at org.junit.Assert.assertEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:633)
at
com.sun.star.lib.uno.environments.remote.TestWorkAt.passedAsyncTest(TestWorkAt.java:75)
at
com.sun.star.lib.uno.environments.remote.JobQueue_Test.testAsyncJobQueue(JobQueue_Test.java:180)
at
com.sun.star.lib.uno.environments.remote.JobQueue_Test.testStaticThreadExecutesAsyncs(JobQueue_Test.java:121)
FAILURES!!!
Tests run: 19, Failures: 1
Change-Id: Iad980aea1245bfd8ee89887b175eb9dc17643778
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163727
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
over 4k hits limit so flush waits until something reads, but the
read is in the same thread after the flush.
We are just using _outputStream to accumulate the bytes to be send
so change this to use a ByteArrayOutputStream and take over its bytes
and clear it when we flush.
Change-Id: I17b90e1c7d4302f153b5832e60ac0e0f2b86ace9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156565
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
because the data written here doesn't appear to the reader
on the other end until a full second expires.
https: //bugs.openjdk.org/browse/JDK-8014239
Change-Id: I9b6f4d51562f4dd0866ff0fccd5951b1efe38f25
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156488
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
- 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 97b61ea329. It checked
that the NativeLibraryLoader is an instance of the class
com.sun.star.lib.unoloader.UnoClassLoader. If this is not the case, a
warning was displayed. This was for java_uno bridge to work.
On the other hand, as the comment in the code implies, "not a problem
if this is using Java remote bridge or (in a) unit test". But, in the
code there was no check for that. As a result, this warning is displayed
in many places like the simple examples that want to connect to the
LibreOffice process via Java API.
Change-Id: I056ed372ad071573051024a63e51afd6b4425ce5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156302
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Tested-by: Jenkins
Reviewed-by: Hossein <hossein@libreoffice.org>
until the buffer is full, or the file ends. It shouldn't care about
available().
(cherry-picked from f04910427d25ede98b84b90df7cc5a12d1adc695)
Change-Id: I4ad17c614ba336ff21883248715861f6af1fbc2b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147934
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Jenkins
methods in InputStreamToXInputStreamAdapter when called from the inter-process UNO bridge.
XInputStream::readBytes() documents how the buffer is an "out" parameter, and isn't passed
to the implementing end, which is why we get the buffer as a "byte[][] b" and b[0] == null.
Its role is to box a byte[] array to be returned the client. Thus, allocate the buffer if
it is missing or too small.
Additionally, virtually all other readBytes() and readSomeBytes() implementations trim this
sequence to the actual number of bytes read. This presumably reduces the inter-process
traffic, but some callers even rely on the sequence to be trimmed, eg.
main/sax/source/expatwrap/xml2utf.cxx. Thus trim our returned array too.
(cherry-picked from 6cb06142790376a2c58e6392182eb071420a4221)
Change-Id: I42eb209b68f7c13a34670d03c2ca61d76672385b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147933
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Jenkins
...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>
The native libraries are local to class loaders, so
System.load("java_uno.so") will fail with any other class loader.
Change-Id: Ifa3b1b8dfef07b64828943654e28ff1f0fb5a494
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120527
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>
Since ae855bf481 and
35518c9236 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>
They are dummies now and empty (except Class-Path:). Thus maven should pull
in libreoffice.jar, too
Change-Id: I63753deddceef6480fd4f5122b4892b707a9dd20
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98929
Tested-by: Jenkins
Reviewed-by: David Ostrovsky <david@ostrovsky.org>
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 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>
See instructions in solenv/gbuild/Trace.mk . This generates a file than
can be viewed e.g. in the Chromium tracing view.
Change-Id: I5f90647c58ca729375525b6daed2d4918adc8188
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88754
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
For one, JunitTest_typedesc and JunitTest_uno don't use qadevOOo at all. And
for another, even for JunitTest_util (which does use qadevOOo), in gbuild it is
OK (and frequently used) for a check target in one module to have dependencies
on higher modules.
Change-Id: I6f6339fa516eb8582d88ada50fabe56784d99dda
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88058
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Andrea Gelmini