Age | Commit message (Collapse) | Author | Files | Lines |
|
This reverts commit dd6c4f4db1d62268d73e09ae52d23f760a967dcc "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
(cherry picked from commit 7ea7fb009ddcfb0723e88ba0c5778b5fdbe2b553)
Reviewed-on: https://gerrit.libreoffice.org/922
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: If58683331c50f2a95204e8e2dea11edbef3ccb63
|
|
Change-Id: I37e225902bf7f3a6e007e7641b2b9898b044a45b
|
|
Change-Id: I30be93ccaeb1f9fd17cbe9e3ed3165e094810b2e
|
|
Change-Id: I7c3409ac39e690fcf2f7e4085bf6857e6bd182fb
|
|
It is done the same way the beanshell is handled.
Currently it can't be enabled by default as internal version has
patched-in debug interface.
We can choose two paths, rewrite the code to the new rhino debug
interface or just strip the current one out.
Change-Id: I48af18c635816db8269f13a649b62e9c454ee1e6
|
|
Do not install the benashell/javascript stuff if they are not actually
bult.
Build rhino only when required by javascript extension.
Change-Id: Icc378524008389af35631c64a1a0288eb4f271be
|
|
this removes dmake completely out of the build for migrated modules
build.pl now assumes modules to be gbuild, unless there is a
prj/dmake file
Change-Id: I674a036b182ee13c5ec093e83cb3d38133112d3b
|
|
...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.
|
|
...detected now that the default service manager XContentEnumerationAccess
no creates its own XServiceInfo instances.
|
|
...otherwise, if it is bundled, its per-user data is not regenerated, leading
to inconsistencies.
|
|
|
|
|
|
|
|
|
|
Naming convention for gbuild methods:
- "add" is used for stuff that is logically a part of the target
(i.e. not registered at the Module, but defined in the target's makefile)
- "use" is used for stuff that is logically a different target
(i.e. it is registered at the Module, has it's own makefile, may be
in a different module than the target)
|
|
|
|
Pattern used:
find . -name "*.cxx" -exec sed -i 's/\( *\)\(else if\|if\) *( *\([^!()|&]*\)\.equalsAsciiL( *RTL_CONSTASCII_STRINGPARAM *( *\([^)]*\)) *) *)$/\1\2 ( \3 == \4 )/' \{\} \;
|
|
Pattern used:
find . -name "*.cxx" -exec sed -i 's/\( *\)\(else if\|if\) *( *\([^!()|&]*\)\.equalsAsciiL( *RTL_CONSTASCII_STRINGPARAM *( *\([^)]*\) ) *) *)$/\1\2 ( \3 == \4 )/' \{\} \;
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
...they contained no class files anymore, due to missing gb_Jar_set_packageroot
calls. However, those calls only work for subdirectories, i.e., the example
.java files need to be put into a package (I chose
org.libreoffice.example.java_scripts) for all of them). This in turn required
adaption of the parcel-descriptor.xml files; not sure what the logicalname
entries there are good for if anything -- the macro names at "Tools - Macros -
Run Macro..." now unfortunately(?) contain the fully qualified paths for the
HelloWorld, HighlightText, and MemoryUpdate examples. There are additional
examples at scripting/examples/java/ that apparently do not get packaged (but I
adapted them anyway).
|
|
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.
|
|
|
|
|
|
|
|
|
|
in scripting / sdext / starmath / stoc / svtools / svx
|
|
|
|
|
|
|
|
to equalsIgnoreAsciiCaseAscii("...")
|
|
|
|
|
|
Any LO-based app distributed through the App Store can't have
scripting or extendability anyway.
Sure, this will break the build elsewhere because of missing headers.
No big deal, I will take care of that eventually. It isn't as if there
would anybody else building for iOS anyway, as far as I know. If there
is, please make yourself heard.
|
|
|
|
|
|
Part XXIX
Modules
sax, scaddins, sccomp, scripting
|
|
|
|
|
|
|
|
|
|
|