Age | Commit message (Collapse) | Author |
|
|
|
|
|
Set up the toolchain to create sources and javadocs artifacts in
addition to JARs created during the build. Use Buck build tool for
that: [1]. This is a fork of Google's build tool Blaze, created by
Xooglers at Facebook. This build tool (like Blaze itself) uses
Python to write build files.
Add needed tools and build files to install LibreOffice API artifacts
to local Maven repository or deploy them to Maven Central.
To build all needed artifacts LibreOffice must be built regularly
with GNU make first. To build the rest of the API (sources and
javadocs):
$> buck build api
To replace version number with upcoming release version:
$> solenv/bin/version.py 5.1.0
To install the API to local Maven repository:
$> buck build api_install
To deploy the API to Maven Central:
$> buck build api_deploy
Detailed documentation is added to document the prerequisites and
the workflow to upload LibreOffice API to Maven Central.
* [1] https://buckbuild.com
Change-Id: Ibdd552a01110836703bc069abe829b9921491cac
Reviewed-on: https://gerrit.libreoffice.org/20343
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
Tested-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
(cherry picked from commit 1fd41f43eb73c373cb94d32d82c5fb7a7e243367)
Reviewed-on: https://gerrit.libreoffice.org/20814
Reviewed-by: David Ostrovsky <david@ostrovsky.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Miklos Vajna <vmiklos@collabora.co.uk>
(cherry picked from commit 95fe7d0a68c230df13c80dd8759f86d635c48101)
|
|
As outlined in the requirements to deploy the artifacts on Maven
Central, the metdata must be provided:
* Project Name, Description and URL
* License Information
* Developer Information
* SCM Information
[1] http://central.sonatype.org/pages/requirements.html
Change-Id: I0bcd19a22d0e1a48f0faec0b414f816f7da5b318
Reviewed-on: https://gerrit.libreoffice.org/20315
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
(cherry picked from commit 9ca2de8c5995657973665189903aa2eebe0ef69a)
Reviewed-on: https://gerrit.libreoffice.org/20813
Reviewed-by: David Ostrovsky <david@ostrovsky.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
(cherry picked from commit 708eab71f4d099a3887d32e59ef817db50324698)
|
|
this is the canonical order, and it makes the code easier to read
Reviewed-on: https://gerrit.libreoffice.org/16242
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: David Ostrovsky <david@ostrovsky.org>
(cherry picked from commit 0c18bedb7328493040c1a20822b345e624d6041f)
Change-Id: I272e7f1e140296e582702b6dbf77a03eefb65470
|
|
The below commit fixes this as bug as a side-effect:
fix use of TCP_NODELAY for localhost URP connections
we implemented this logic in the C++ URP code a while back, but the Java
code was not correctly updated.
Reviewed-on: https://gerrit.libreoffice.org/17427
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Tested-by: Noel Grandin <noelgrandin@gmail.com>
(cherry picked from commit 9ffdcc76858bc01150727345de4dfd0ef40ed8c0)
Change-Id: I377d7150f1adb69d6f86d9b4f3406163aaf85aea
Reviewed-on: https://gerrit.libreoffice.org/17708
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
Tested-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
|
|
Change-Id: I22a5b9fa29d465a21e682279e6e88d37bd8adf93
|
|
Change-Id: Id2b645829ceb9affc76483a651fe6830a9f01cda
|
|
it can make a significant speed difference for applications
talking to the office binary via UNO
Change-Id: If6e901908fe6a6119ac1fd0bf8feebabe5602ff7
Reviewed-on: https://gerrit.libreoffice.org/13856
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Tested-by: Noel Grandin <noelgrandin@gmail.com>
|
|
Change-Id: Ifd23373b1ac4919793d1b4251ed90cf2dd6f2bda
|
|
found by UCDetector
Change-Id: I6b0f49529379072da566e927b86815f173e7a90b
|
|
and just use OOoRunner, there is no point in having a stripped down
jar, the cost of firing up the Java VM completely dwarfs any benefit
of having a smaller jar.
Change-Id: Ibcc3c5bd6e9b9c918041142dd32db0ea5dddc25b
Signed-off-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I5d6071096307adbe7df0178000346cf915afa3e7
Reviewed-on: https://gerrit.libreoffice.org/13477
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Tested-by: Noel Grandin <noelgrandin@gmail.com>
|
|
Change-Id: Icd966a850b7c5e276e8b1d74566a4ea02e5b4a5c
|
|
found by PMD
Change-Id: Id6737916b68ccbdbdeec5d314747a38410923ac6
Reviewed-on: https://gerrit.libreoffice.org/13409
Tested-by: LibreOffice gerrit bot <gerrit@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
|
|
AsynchronousFinalizer was originally added as
870a4401c05beec3d31c1f6055a64591edd0a9d9 "INTEGRATION: CWS mtg1: #i57753# Avoid
long-running finalize methods" referring to
<https://issues.apache.org/ooo/show_bug.cgi?id=57753> " Fix JNI-UNO bridge so
that the JVM doesn't run out of memory when a destructor locks the SolarMutex."
It is unclear to me how relevant "If JVMs are getting more mature and should no
longer have problems with long-running finalize methods, this class could be
removed again" really is in practice. After all, advice on hotspot-gc-devel is
to avoid finalize() if possible
(<http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2014-June/010215.html>
"Re: History of finalizer execution and gc progress?"). So stick with this
approach of home-grown draining for now (where a home-grown approach using
PhantomReferencens would need a dedicated draining thread, too, so would not
have much benefit over the existing code in practice).
Timely termination of AsynchronousFinalizer threads is achieved by using a
dedicated thread per bridge and joining it in the remote bridge's dispose()
resp. the JNI environment's new java_env_dispose.
Change-Id: Idcef2dbf361a1de22f60db73828f59e85711aea7
|
|
Change-Id: I49f3f59c76bd4dd078f7014b6a0450241214db7f
|
|
- Remove the LoadLibrary from DLLMain (from windows not recommended)
see http://msdn.microsoft.com/en-us/library/windows/desktop/ms682583(v=vs.85).aspx
in section Remarks
- Improve the comment why we need two dll's (jpipe.dll and jpipx.dll)
- Integrate CriticalSection, init in DllMain see link
http://msdn.microsoft.com/en-us/library/windows/desktop/dn633971(v=vs.85).aspx#general_best_practices
Signed-off-by: Stephan Bergmann <sbergman@redhat.com>: removed the unsafe module
== NULL check around the critical section in getFunction
Change-Id: I6d5f655a4942437f6dc722236f6c371063e2c407
|
|
Change-Id: Ia01528460e2f4b610d123e29cad66520abc6a965
|
|
...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
|
|
Change-Id: I6d9f43a18e13cb291cb678b6faeeed7c0ec9de1a
|
|
Change-Id: I0c9659379e6120c0bf01b6436d3127b83ad01af1
|
|
Change-Id: Ida0c3c0c521f71fd3f18a12c02cf98ac96c5b7a6
|
|
Change-Id: I24ebffd1b055bdd6ad93d2f071d20480b549379f
|
|
Change-Id: I87d977aabd09ff01cba0f25247dca43a2bf0dd2b
|
|
found by PMD
Change-Id: I87780366119c141cd2dafe6ca1bf2d9798b10aec
|
|
Change-Id: I1ab4e23b0539f8d39974787f226e57a21f96e959
Reviewed-on: https://gerrit.libreoffice.org/12164
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Tested-by: Noel Grandin <noelgrandin@gmail.com>
|
|
Change-Id: I1785c6cef1fe7c1990207a76c263cff388cbb7e1
Reviewed-on: https://gerrit.libreoffice.org/12375
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Tested-by: Noel Grandin <noelgrandin@gmail.com>
|
|
by using early return in some methods
Change-Id: I3611c8c89b3a94ef7e1772d178acf065fd7fcdc7
Reviewed-on: https://gerrit.libreoffice.org/12374
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Tested-by: Noel Grandin <noelgrandin@gmail.com>
|
|
Change-Id: Ia43976d84eede6f699381bc4f3daf89b95e4cb4f
Reviewed-on: https://gerrit.libreoffice.org/12150
Reviewed-by: Bryan Quigley <gquigs@gmail.com>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
Tested-by: Michael Stahl <mstahl@redhat.com>
|
|
Change-Id: Ic058759782f95e330d8c581911aeb163340a7c4b
|
|
Change-Id: I34ce000c48d2d79bfec854c8dd55d12f2bee29c7
|
|
Change-Id: Iff896b0cace8b8305528b3b0140004ea856169ce
|
|
Change-Id: I3c0c7f08d4d8ea594e72fc0d9b93d085d4ab4bf5
|
|
Change-Id: I76431b67f9f6fdde2906d6d8082457ef0847108e
Reviewed-on: https://gerrit.libreoffice.org/11964
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Tested-by: Noel Grandin <noelgrandin@gmail.com>
|
|
Change-Id: I1bb0999783f365e20b682c3707e73c65724265c9
Reviewed-on: https://gerrit.libreoffice.org/11955
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Tested-by: Noel Grandin <noelgrandin@gmail.com>
|
|
Change-Id: I58e7ebdd5c48094142f93f47271bcc0cc8b97981
Reviewed-on: https://gerrit.libreoffice.org/11892
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Tested-by: Noel Grandin <noelgrandin@gmail.com>
|
|
Change-Id: I597dac3cae7eafef75982789ab1b0d3d8d6999d2
Reviewed-on: https://gerrit.libreoffice.org/11863
Reviewed-by: Samuel Mehrbrodt <s.mehrbrodt@gmail.com>
Tested-by: Samuel Mehrbrodt <s.mehrbrodt@gmail.com>
|
|
the instanceof check returns false when passed a null value
Change-Id: I7742d0d9cf25ef23d9adee7328f701c7efeea8b5
|
|
Change-Id: I6cb46a51dda3fda51a3b6413656da15fc5bdb04d
|
|
Change-Id: I01a521f5d5104bf2e6046330e2d667155c27a604
|
|
the java.io.IOException(Throwable) constructor was only introduced
in 1.6
Change-Id: Icd40e91cce7a2e89e4a70ad55f31baaa86eebfe2
|
|
Change-Id: I4393b59d7d3a285160d6090847d9a16676f41f4d
Reviewed-on: https://gerrit.libreoffice.org/11677
Reviewed-by: David Ostrovsky <david@ostrovsky.org>
Tested-by: David Ostrovsky <david@ostrovsky.org>
|
|
so that we get a nice complete stacktrace when it hits the final
handler
Change-Id: Iec4fcc15a2a25c55f591b5e069dce3d010197a90
|
|
Change-Id: I914985aa73653e0fb08200ddd06ad5b914087e3a
Reviewed-on: https://gerrit.libreoffice.org/11446
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Tested-by: Noel Grandin <noelgrandin@gmail.com>
|
|
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
|
|
Change-Id: I611821d5f84b440ba542a8d62a374df7b505de15
|
|
Change-Id: I8e70a62959dbeecd571c15c5b6fac1a41511a3f6
|