Re: [dev] A few brief questions ad extension packages (Re: [dev] Class-Path Entry in Manifest Package File and the Location of the Respective jars?
Hi there,
sorry, was off for a week witohut access to e-mail, hence my late answer
(keeping the quotings so only this e-mail is needed).
Stephan Bergmann wrote:
Rony G. Flatscher wrote:
Hi Stephan,
, in the case of the ooRexx scripting engine:
* there is a platform dependent DLL/so which needs to be
accessible
(at the moment I copy it into OOoHome/program), so the library
is *not* an UNO-component, just a native library,
* there are three text files (actually ooRexx programs) named
BSF.CLS, UNO.CLS, UNO_XINTERFACES.REX which also need to be
accessible by ooRexx scripts (and for that reason I have to copy
them into OOoHome/program.
Which code accesses those files (the shared lib and the Rexx programs)
how, and why does it help to move them to the program directory? (If
it is clear how those files are accessed, there might be a way to
access them directly within the extension.)
Code which is invoked via the OOo scripting framework, here's what
happens:
* An ooRexx macro is invoked via Tools-Macro
* the Java support part for the scripting language uses BSF (Apache
Java archive) to load the Rexx interpreter (via the DLL/so
residing in OOHome/program) and supplies the script and makes the
arguments available to it;
I still do not understand how the DLL/so residing in OOHome/program
(lets call it X) is loaded. Is it supplying UNO services/singletons
and is thus loaded via the UNO framework?
Yes, the ooRexx script provider package for OOo adheres to UNO
(ScriptProviderForooRexx.jar) which invokes bsf.jar (an Apache.org jar
which invokes the DLL/so via JNI, which then invokes the ooRexx
interpreter).
Is it loaded from some Java code Y via System.loadLibrary? Is it
loaded from some native code Z via dlopen?
If an ooRexx script is run by OOo, then the ooRexx script provider
package (ScriptProviderForooRexx.jar) is used to dispatch the macro
using bsf.jar which uses JNI to load the [lib]BSF4Rexx.{dll|so}which
then will load the ooRexx interpreter and supply the macro for
execution. Such ooRexx macros need access to UNO.CLS (which itself needs
access to BSF.CLS and UNO_XINTERFACES.REX) to make it really easy to
interface with OOo. Placing the DLL/so and the ooRexx files (plain
textfiles) into $OOO_HOME/program makes the ooRexx script provider run
successfully, i.e., these files will be found.
Therefore I have been under the impression, that OOo sets that directory
($OOO_HOME) to the PATH (and maybe LD_LIBRARY_PATH on Linux systems?)
environment variable, as otherwise these files could hardly be found.
* the Rexx interpreter executes the script which itself calls
UNO.CLS (specific UNO/OOO support, which itself uses
UNO_XINTERFACES.REX), which calls BSF.CLS (bridge to Java); all
these scripts are plain text files and are found in their location
(OOHome/program).
*Why* are they found in the program directory?
Good question (but I am *very* happy that they are found!) !
:)
Does the Rexx interpreter (is that the library X above?) look next to
itself for them? (That is, if the Rexx interpreter were instead
located in your extension, would those text files automatically be
found in your extension, too?)
The Rexx interpreter is not placed in the script provider package, but
accessible globally (on Windows it is installed for all users, on Linux
it is installed in /opt and the executable is linked to /usr/bin the
librexx.so to /usr/lib). So the interpreter lives independently of OOo,
but every process can access it given the above environment setup.
HTH,
---rony
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] A few brief questions ad extension packages (Re: [dev] Class-Path Entry in Manifest Package File and the Location of the Respective jars?
Stephan Bergmann wrote: Rony G. Flatscher wrote: Hi Stephan, Feel free to come back here with any questions along your way, Thank you very much for your kind offer! Indeed, after studying your information there would be a couple of questions: * where would one find the full definition for manifest.xml and a list of valid mainfest:media-types; I looked in the developers guide and tried the search function of the Wiki, but have not been really able to locate it? Maybe its only in the code. :( But I do not know, maybe Jochen knows more. Jochen??? The Developers Guide (I believe chapter 4.9 contains the information about what possible entries can exist. * also, where would one be able to find the full definition for the description.xml file? o ad version numbers: would something like 2.1.0.20070202 or 210.20070202 be o.k. (according to the production rule it should be possible) or would that pose any problems (the date of the version is the trailing value, possibly supplemented with the time of the day like 210.20070202162200) The authoritative definition of version numbers is http://specs.openoffice.org/appwide/packagemanager/extensionversion.odt. All your examples above would be valid version numbers. However, the TODO at desktop/source/deployment/misc/dp_version.cxx:1.3 l. 53 suggests to only use segments for now that represent integers 2^63. ;) * ad application/vnd.sun.star.uno-component;type=native: o This can be used to not only denote libraries, but also executables and modules (or with other words: these files will be put into a place that is accessible via the PATH settings?) No, such files are not put on any path. If those libraries are UNO libraries that support services/singletons, they will be found by the UNO framework via the information recorded at deployment time. If those libraries are used by other libraries, those libraries must make sure to find them (e.g., via RPATH on ELF platforms). o Is there a complete list somewhere of the operating system dependent strings? The extension document mentions Windows, Linux_x86, Solaris_SPARC. So what about PPC versions of Linux or Intel versions of Solaris or PPC and/or Intel versions of MacOSX? AFAIK these values are composed of the build- in bootstrap variables _OS and _ARCH. Values for these can be found in sal/rtl/source/macro.hxx. Jochen Again, maybe its only in the code. Again, maybe Jochen knows more. * is there a possibility to copy a set of scripts (in any available scripting language) to the user and/or shared script repository? If possible, what would be the appropriate manifest:media-type entry? o Of course this may pose a little problem when using the update feature, as such scripts could have been edited in the meantime by the users (but then one could resolve this by moving the existing/edited extension scripts to an own backup library) Sorry, I have no experience with those things. Hopefully, somebody else can step in. -Stephan TIA, ---rony - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] A few brief questions ad extension packages (Re: [dev] Class-Path Entry in Manifest Package File and the Location of the Respective jars?
Rony G. Flatscher wrote: Hi Stephan, thank you very much for your answers! ... cut ... * ad application/vnd.sun.star.uno-component;type=native: No, such files are not put on any path. If those libraries are UNO libraries that support services/singletons, they will be found by the UNO framework via the information recorded at deployment time. If those libraries are used by other libraries, those libraries must make sure to find them (e.g., via RPATH on ELF platforms). Hmm, in the case of the ooRexx scripting engine: * there is a platform dependent DLL/so which needs to be accessible (at the moment I copy it into OOoHome/program), so the library is *not* an UNO-component, just a native library, * there are three text files (actually ooRexx programs) named BSF.CLS, UNO.CLS, UNO_XINTERFACES.REX which also need to be accessible by ooRexx scripts (and for that reason I have to copy them into OOoHome/program. Is there a means with the extension package manager (via a manifest:media-type) to cause these files to be either made accessible via [D]PATH/LD_LIBRARY_PATH and PATH, or have a means available to tell the package manager where to copy these files in the standard OOo installation tree in a platform independent manner)? No, only libraries containing UNO services can be installed. Jochen Regards, ---rony - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] A few brief questions ad extension packages (Re: [dev] Class-Path Entry in Manifest Package File and the Location of the Respective jars?
Rony G. Flatscher wrote: Hi Stephan, thank you very much for your answers! ... cut ... * ad application/vnd.sun.star.uno-component;type=native: No, such files are not put on any path. If those libraries are UNO libraries that support services/singletons, they will be found by the UNO framework via the information recorded at deployment time. If those libraries are used by other libraries, those libraries must make sure to find them (e.g., via RPATH on ELF platforms). Hmm, in the case of the ooRexx scripting engine: * there is a platform dependent DLL/so which needs to be accessible (at the moment I copy it into OOoHome/program), so the library is *not* an UNO-component, just a native library, * there are three text files (actually ooRexx programs) named BSF.CLS, UNO.CLS, UNO_XINTERFACES.REX which also need to be accessible by ooRexx scripts (and for that reason I have to copy them into OOoHome/program. Which code accesses those files (the shared lib and the Rexx programs) how, and why does it help to move them to the program directory? (If it is clear how those files are accessed, there might be a way to access them directly within the extension.) Is there a means with the extension package manager (via a manifest:media-type) to cause these files to be either made accessible via [D]PATH/LD_LIBRARY_PATH and PATH, or have a means available to tell the package manager where to copy these files in the standard OOo installation tree in a platform independent manner)? No, neither. Regards, ---rony - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] A few brief questions ad extension packages (Re: [dev] Class-Path Entry in Manifest Package File and the Location of the Respective jars?
Rony G. Flatscher wrote: Hi Stephan, , in the case of the ooRexx scripting engine: * there is a platform dependent DLL/so which needs to be accessible (at the moment I copy it into OOoHome/program), so the library is *not* an UNO-component, just a native library, * there are three text files (actually ooRexx programs) named BSF.CLS, UNO.CLS, UNO_XINTERFACES.REX which also need to be accessible by ooRexx scripts (and for that reason I have to copy them into OOoHome/program. Which code accesses those files (the shared lib and the Rexx programs) how, and why does it help to move them to the program directory? (If it is clear how those files are accessed, there might be a way to access them directly within the extension.) Code which is invoked via the OOo scripting framework, here's what happens: * An ooRexx macro is invoked via Tools-Macro * the Java support part for the scripting language uses BSF (Apache Java archive) to load the Rexx interpreter (via the DLL/so residing in OOHome/program) and supplies the script and makes the arguments available to it; I still do not understand how the DLL/so residing in OOHome/program (lets call it X) is loaded. Is it supplying UNO services/singletons and is thus loaded via the UNO framework? Is it loaded from some Java code Y via System.loadLibrary? Is it loaded from some native code Z via dlopen? * the Rexx interpreter executes the script which itself calls UNO.CLS (specific UNO/OOO support, which itself uses UNO_XINTERFACES.REX), which calls BSF.CLS (bridge to Java); all these scripts are plain text files and are found in their location (OOHome/program). *Why* are they found in the program directory? Does the Rexx interpreter (is that the library X above?) look next to itself for them? (That is, if the Rexx interpreter were instead located in your extension, would those text files automatically be found in your extension, too?) -Stephan Regards, ---rony - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] A few brief questions ad extension packages (Re: [dev] Class-Path Entry in Manifest Package File and the Location of the Respective jars?
Hi Stephan, Feel free to come back here with any questions along your way, Thank you very much for your kind offer! Indeed, after studying your information there would be a couple of questions: * where would one find the full definition for manifest.xml and a list of valid mainfest:media-types; I looked in the developers guide and tried the search function of the Wiki, but have not been really able to locate it? * also, where would one be able to find the full definition for the description.xml file? o ad version numbers: would something like 2.1.0.20070202 or 210.20070202 be o.k. (according to the production rule it should be possible) or would that pose any problems (the date of the version is the trailing value, possibly supplemented with the time of the day like 210.20070202162200) * ad application/vnd.sun.star.uno-component;type=native: o This can be used to not only denote libraries, but also executables and modules (or with other words: these files will be put into a place that is accessible via the PATH settings?) o Is there a complete list somewhere of the operating system dependent strings? The extension document mentions Windows, Linux_x86, Solaris_SPARC. So what about PPC versions of Linux or Intel versions of Solaris or PPC and/or Intel versions of MacOSX? * is there a possibility to copy a set of scripts (in any available scripting language) to the user and/or shared script repository? If possible, what would be the appropriate manifest:media-type entry? o Of course this may pose a little problem when using the update feature, as such scripts could have been edited in the meantime by the users (but then one could resolve this by moving the existing/edited extension scripts to an own backup library) TIA, ---rony
Re: [dev] A few brief questions ad extension packages (Re: [dev] Class-Path Entry in Manifest Package File and the Location of the Respective jars?
Rony G. Flatscher wrote: Hi Stephan, Feel free to come back here with any questions along your way, Thank you very much for your kind offer! Indeed, after studying your information there would be a couple of questions: * where would one find the full definition for manifest.xml and a list of valid mainfest:media-types; I looked in the developers guide and tried the search function of the Wiki, but have not been really able to locate it? Maybe its only in the code. :( But I do not know, maybe Jochen knows more. Jochen??? * also, where would one be able to find the full definition for the description.xml file? o ad version numbers: would something like 2.1.0.20070202 or 210.20070202 be o.k. (according to the production rule it should be possible) or would that pose any problems (the date of the version is the trailing value, possibly supplemented with the time of the day like 210.20070202162200) The authoritative definition of version numbers is http://specs.openoffice.org/appwide/packagemanager/extensionversion.odt. All your examples above would be valid version numbers. However, the TODO at desktop/source/deployment/misc/dp_version.cxx:1.3 l. 53 suggests to only use segments for now that represent integers 2^63. ;) * ad application/vnd.sun.star.uno-component;type=native: o This can be used to not only denote libraries, but also executables and modules (or with other words: these files will be put into a place that is accessible via the PATH settings?) No, such files are not put on any path. If those libraries are UNO libraries that support services/singletons, they will be found by the UNO framework via the information recorded at deployment time. If those libraries are used by other libraries, those libraries must make sure to find them (e.g., via RPATH on ELF platforms). o Is there a complete list somewhere of the operating system dependent strings? The extension document mentions Windows, Linux_x86, Solaris_SPARC. So what about PPC versions of Linux or Intel versions of Solaris or PPC and/or Intel versions of MacOSX? Again, maybe its only in the code. Again, maybe Jochen knows more. * is there a possibility to copy a set of scripts (in any available scripting language) to the user and/or shared script repository? If possible, what would be the appropriate manifest:media-type entry? o Of course this may pose a little problem when using the update feature, as such scripts could have been edited in the meantime by the users (but then one could resolve this by moving the existing/edited extension scripts to an own backup library) Sorry, I have no experience with those things. Hopefully, somebody else can step in. -Stephan TIA, ---rony - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] A few brief questions ad extension packages (Re: [dev] Class-Path Entry in Manifest Package File and the Location of the Respective jars?
Hi Stephan, thank you very much for your answers! ... cut ... * ad application/vnd.sun.star.uno-component;type=native: No, such files are not put on any path. If those libraries are UNO libraries that support services/singletons, they will be found by the UNO framework via the information recorded at deployment time. If those libraries are used by other libraries, those libraries must make sure to find them (e.g., via RPATH on ELF platforms). Hmm, in the case of the ooRexx scripting engine: * there is a platform dependent DLL/so which needs to be accessible (at the moment I copy it into OOoHome/program), so the library is *not* an UNO-component, just a native library, * there are three text files (actually ooRexx programs) named BSF.CLS, UNO.CLS, UNO_XINTERFACES.REX which also need to be accessible by ooRexx scripts (and for that reason I have to copy them into OOoHome/program. Is there a means with the extension package manager (via a manifest:media-type) to cause these files to be either made accessible via [D]PATH/LD_LIBRARY_PATH and PATH, or have a means available to tell the package manager where to copy these files in the standard OOo installation tree in a platform independent manner)? Regards, ---rony
