Change all instances of hardcoded "program", "share" etc subfolder names to
use those from <config_folders.h> instead. In normal builds, the end result
will not change.
Change-Id: I91c95cd8e482818be67307e889ae6df887763f53
... derives from com.sun.star.uno.RuntimeException instead of
com.sun.star.uno.Exception.
Only test that breaks with this change is jurt_uno/AnyConverter_Test,
which for mysterious reasons effectively tests that
IllegalArgumentException is a subclass of Exception and not
RuntimeException. Presumably this is just a generic exception test that
happens to use IllegalArgumentException.
Some further testing indicates there are no problems expected at
runtime:
Running "make subsequentcheck" with all Java test code compiled against
a ridl.jar that does not contain the change, running against a soffice
that uses ridl.jar and rdbs with the change + ridl.jar with the change
on the test side yields exactly the same AnyConverter_Test failure, with
no other failures.
Change-Id: Iad183de76ec7e0d56648084e97cdcc160b5b033d
This reverts commit dd6c4f4db1 "fdo#46102: Load
Java scripts with class loaders that actually find them." That commit broke
support for macros embedded in documents (as
new java.net.URL("vnd.sun.star.tdoc:...") throws a MalformedURLExcetpion), and
it looks like that commit was not necessary after all -- or rather that what it
tried to work around must have been some other problem that has been fixed
meanwhile. "It is unclear to me how the Java script provider shall ever have
found the script jars in the past" indicates that something must have been
fishy, and what I failed to notice back then is that createURL creates
java.net.URL instances with a UCBStreamHandler that does allow to obtain content
from weird-looking URLs.
Anyway, with that reverted, all three following scenarios work on both current
master (towards LO 3.7) and libreoffice-3-6 (towards LO 3.6.4); I haven't yet
come around to test on libreoffice-3-5:
1 Stock macros, "Tools - Macros - Run Macro... - LibreOffice Macros -
HelloWorld", running all of the four "helloworld.bsh", "helloworld.js",
"HelloWorldPyhton", and
"org.libreoffice.example.java_scripts.HelloWorld.printHW".
2 Per-document macros, loading test.odt attached to fdo#49517, then "Tools -
Macros - Run Macro... - test.odt - HelloWorld", running
"org.libreoffice.example.java_scripts.HelloWorld.printHW".
3 Extension macros, installing ScriptDispatch.oxt attached to fdo#46012 as
shared extension, then loading StartScriptDispatch.odt attached to fdo#46012 and
pressing the "Start Java via ScriptProvider" button.
Change-Id: I31cd16b3720ffeb1058722d4d1fdffb773f8a067
This patch remove some '@author' for Java souce files, and removes some commented code founded
when removing the '@author'.
Change-Id: I7bff1507212e967069f3d18e6c1040f69501694a
Signed-off-by: Marcos Paulo de Souza <marcos.souza.org@gmail.com>
* As UCB is only ever initialized with "Local"/"Office", remove this
configuration vector completely. The "create" ctor creates an instance
internally initialized with those "Local"/"Office" keys. Special (test) code
can still instantiate an uninitialized one via plain createInstance. And for
backwards compatilibity process startup still ensures to create an initialized
instance early, in case there is still code out there (in extensions) that
later calls plain createInstance and expects to get the already-initialized
(single) instance.
* XInitialization is an "implementation detail" of the UniversalContentBroker
service, do not expose in XUniversalContentBroker.
* ucbhelper/configurationkeys.hxx is no longer needed and is removed.
* ucbhelper/contentbroker.hxx is an empty wrapper and is removed; however, that
requires ucbhelper::Content constructors to take explicit XComponentContext
arguments now.
* The only remaining code in ucbhelper/source/client/contentbroker.cxx is
Android-only InitUCBHelper. Is that relevant still?
Change-Id: I3f7bddd0456bffbcd13590c66d9011915c760f28
...that are no longer bundled extensions. Otherwise, old user data where these
were still recorded as bundled extensions could cause execeptions at start up
about duplicate implementations.
ScriptMetaData.createURL produces weird URLs (ending in "/ucb/", and potentially
still containing vnd.sun.star.expand: prefix) that are apparently good for
loading documents for editing via UCBStreamHandler, but cannot meaningfully be
passed to a URLClassLoader.
It is unclear to me how the Java script provider shall ever have found the
script jars in the past.
Their jar files reference other non-URE jars, so they cannot be extensions.
bsh.jar has been moved into the optional module (it used to be installed
always, but it looks like only the bsh script provider needs it; also, it
had been added to URE_MORE_JAVA_CLASSPATH_URLS if SYSTEM_BSH, which also
appears unnecessary as it is mentioned with an absolute file URL in the
Class-Path of the script provider jar).
js.jar has been included in the optional module (it used to be not installed
at all?).
