...using Java 1.4 java.util.logging.Logger instead also for the last remaining
uses in reportbuilder.
(The mention in swext/mediawiki/src/THIRDPARTYLICENSEREADME.html was presumably
a leftover from 4b6ceed4a4 "swext: Wiki Publisher
does not use those apache-commons libraries".)
Change-Id: Ia0bc598fe5844ced11cae497548ec7d09453a99d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113939
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
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>
The extension Cite is distributed with MediaWiki 1.21 (released May 2013) and is integrated in core since MediaWiki 1.25. No need to keep that notice any longer.
Change-Id: I8a91fbb45bc6f410b551c206177d63c584349c37
Reviewed-on: https://gerrit.libreoffice.org/51795
Reviewed-by: Olivier Hallot <olivier.hallot@libreoffice.org>
Tested-by: Olivier Hallot <olivier.hallot@libreoffice.org>
To find main url in header section, search link containing:
- load.php
- or opensearch_desc.php
In Wikipedia or wiki.documentfoundation.org, I haven't seen any link with index.php
Change-Id: Iccb27aa8aaaf936faf8ec3b3f67eaa98d0426f19
Reviewed-on: https://gerrit.libreoffice.org/38631
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
It'll change nothing since InsertThrobber function (which contains these args)
are called with value=10 for both vars
Just for sanity sake then
Change-Id: Ie084a5a3cb15a121574aa0d06b43f1a6d34c0d09
Reviewed-on: https://gerrit.libreoffice.org/38639
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
There's a newline in case of heading, table or bibliography following text:p
ok but only if we're not in text:note node
Change-Id: I71172751a51e29abdd770e758d27b1bc8f15cb0d
Reviewed-on: https://gerrit.libreoffice.org/38470
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Julien Nabet <serval2412@yahoo.fr>
and thus callStatusListener does nothing
so there seems no reason to have a m_statusListeners
which is filled by addStatusListener but not emptied by
removeStatusListener
Change-Id: I7efdf7ccfd123bf7c2aa6add4f8db969a0019089
JRE 6 has sufficient HttpURLConnection etc. stuff to make this work
without bundling external libraries.
Change-Id: I6c71980c718169024006f02a96c442a71d798d55
Andras Timar