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