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.
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)
...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.
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.
