Age | Commit message (Collapse) | Author |
|
changed type of several parameters of the functions
jfw_plugin_getAllJavaInfos and jfw_plugin_getJavaInfoByPath
from rtl_uString to OUString
Change-Id: I80feb311542e6ccded9f9924f800c75a7e14a1e7
Signed-off-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I88def7e41a31948d1d7205cd5522b63de6be5f80
|
|
extracted the (duplicate) code which is responsible to check the Java
version requirements in the two functions
"jfw_plugin_getAllJavaInfos" and "jfw_plugin_getJavaInfoByPath"
Change-Id: I8acb198c4b4aaee77dc84bc42ff1fc2e0da2aba7
Signed-off-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Ia1e9d2b31698db23029e4dd5f0f7659acff5d30f
Reviewed-on: https://gerrit.libreoffice.org/12951
Reviewed-by: Michael Stahl <mstahl@redhat.com>
Tested-by: Michael Stahl <mstahl@redhat.com>
|
|
Sadly cannot forward declare "struct {...} TimeValue;".
rtl/(u)?string.hxx still include sal/log.hxx but removing osl/diagnose.h
was painful enough for now...
Change-Id: Id41e17f3870c4f24c53ce7b11f2c40a3d14d1f05
|
|
Change-Id: I35e1eed91a23d2b993398fb39e47e21ca9c0a055
|
|
Added clear() method to OString and OUString class, Updated appropriate call-sites.
Change-Id: I0ba97fa6dc7af3e31b605953089a4e8e9c3e61ac
Signed-off-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I1ab4e23b0539f8d39974787f226e57a21f96e959
Reviewed-on: https://gerrit.libreoffice.org/12164
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Tested-by: Noel Grandin <noelgrandin@gmail.com>
|
|
This reverts commit 05050cdb23de586870bf479a9df5ced06828d498,
not all places that use e.g. OStringToOUString to convert potential UTF-8
are guaranteed to fulfil the prerequisites necessary to use fromUtf8 (and
some places like e.g. in codemaker are happy with the best-effort effect
of OStringToOUString's OSTRING_TO_OUSTRING_CVTFLAGS).
|
|
Change-Id: I771004b7ccab3344a67e827e45bc34c22ffa5f77
|
|
Change-Id: I14c0c5d90b67000cb4fe9e6be647854abfe784da
|
|
they are largely unnecessary these days, since our OUString infrastructure
gained optimised handling for static char constants.
Change-Id: I07f73484f82d0582252cb4324d4107c998432c37
|
|
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: I61e55095b4f74fd619a26cba88dd177d0e318154
|
|
should silence warning, still actually
avoid dlclose on the non-error path
Change-Id: Ibc522bf1067feb04def7d7284eee59878ddc6f47
|
|
Change-Id: Iea1b6354764db0a22976b3de49bf3e22ccb7243e
|
|
Change-Id: I1902c73a72f29e948e479a2ae4776f2dff77b2b5
|
|
Change-Id: I3c134c27db4c1496fcacc519da68af10ab3ce574
|
|
Change-Id: If6b9355c6992eb6651f71c0944a93af0856ef1c7
|
|
Change-Id: I1377dfded1246c8e96db3addc28489886c7f2d99
|
|
Change-Id: I5d596f85fe11bc9336e1669d571795f3dfc70c6c
|
|
Change-Id: I070fb24e9466d697a6014bd65635f6cda8736819
|
|
There surely are no Apple JVMs for other OSes than OS X.
Correspondingly, there surely are no IBM, Blackdown, BEA, FSF or
FreeBSD JVMs for OS X. At least not ones that would be relevant today.
Change-Id: I0ee6f904665a2145771802beffe54268718bef50
|
|
Change-Id: I152f22728a8eeea65114fe102511940bccf40478
Signed-off-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I954f789d5850e8016f5900812f9aa99be2416ce4
|
|
...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
|
|
Change-Id: I323ab12c634d3baa4f624b63d7d483112c23192c
|
|
Change-Id: I53b69a488c70769cbb841db519bc28fd211dc087
|
|
Change-Id: Ibfcd6678ed1503cfab0881f3ec67c4c158d798cb
|
|
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: I1793d2eab568f4a65813fca7257c74e1a85a0090
|
|
Change-Id: Iaf115f1f11aef69ef5dba7023f4126c22d1f49ff
|
|
Change-Id: I37044a37348b203944a8eb9d2204e619055f069d
|
|
Change-Id: Ib57f44c203ead68102d712ef29ab7362b0cea8db
|
|
Change-Id: Ia5be6b5893abef084b5e4203f9f02919289ce055
Reviewed-on: https://gerrit.libreoffice.org/11054
Reviewed-by: David Tardon <dtardon@redhat.com>
Tested-by: David Tardon <dtardon@redhat.com>
|
|
Change-Id: Iff9e2e0ac9921b0d9d36a49fdcd2323d5dd124ee
|
|
almost certainly won't get us too far, but a start
Change-Id: Ic20b97a97b6d506c32322173bd8332d15c3a4555
|
|
i.e. stuff like "x == true"
Change-Id: Ib82a4a30e736df392405332fa197b588482cffcf
|
|
Find "missing headers," where a function is declared directly in the
.cxx (as extern) and not defined, and should arguably instead be declared
in an include file.
Change-Id: I6d83ee432b2ab0cd050aec2b27c3658d32ac02a2
|
|
Change-Id: Id7c517fb37bc28797c45fc0dde83e866f2aa4aac
|
|
Change-Id: I1f44dd938bd0033ad4a5b6af4d24d1ba3e76d852
|
|
Change-Id: I243ecb42d7ba2ce58f4c1a0bf97ad74de947d8bd
|
|
Change-Id: I4bdfb074b3cf6fcb49765322308dfa4b9ed67713
|
|
(which loplugin:unreffun did not catch, as it was referenced by a
friend declaration in vendorbase.hxx)
Change-Id: I8a1afd4699b56425b580c1e63557342ee7ec1cb2
|
|
Change-Id: I43e388df118b9e08ab8c05cad31871ef0af35164
|
|
Change-Id: I6d5a952901648e01904ef5c37f953c517304d31e
|
|
Change-Id: I42119f656ca528286fb25d2d36c0af54b7d04a6b
|
|
Change-Id: I9464179a736b91f5bc32eb5e5e89b3b4e3da3494
|
|
Change-Id: I3e6b081711a45e6e0d77c6288ad26214b95b3dc7
|
|
With just the Oracle JRE installed, it is not possible to load the
"jvm.dll" directly, because the required MSVC runtime DLL is not
found (unless some other software happens to install it system-wide),
as described in http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7184978
There was a hack "do_msvcr71_magic" to manually load the runtime that
is bundled with Oracle JRE 6 and this generalizes that to work with the
MSVCR100.DLL that is bundled with Oracle JRE 7 as well.
An additional adaption of the virtual addresses in the file is done,
and it's a mystery whether it even worked before without that.
This issue was not user-visible before because LO releases 3.5 - 4.2
bundle the MSVCR100.DLL themselves.
Change-Id: If61565df80ff8a68472a76000ab5b10d6c78e11c
|