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]
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 hints and pointers, which I need to follow and study in full in order to be able to experiment with it! (Will take some time, though.) If the three additional jars (bsf-v242-20070128.jar, bsf-rexx-engine.jar, oorexx-uno.jar) are only needed by ScriptProviderForooRexx.jar, create a ScriptProviderForooRexx.oxt extension (see http://api.openoffice.org/files/documents/22/3887/Extensions.pdf) instead that contains all four jars (and can also contain additional information like extension identifier, version, update information, see http://wiki.services.openoffice.org/wiki/Extensions_packaging). That way, your functionality (a script provider for ooRexx) comes as a self-contained entity (that can be deployed in one step via unopkg or OOo's Tools - Extension Manager...), without the need to add additional jars to special places (OOo's program/classes, JVM's extension path). That sounds exactly what I have been looking for (in addition I will have to supply platform dependent DLLs/so platforms and supportive - platform independent - scripts), could glimpse over it already a bit and saw that link libraries can be bundled for different platforms. Yes, platform specific libraries are supported. Also, I should point out that the Extensions.pdf is work in progress that is supposed to be integrated into the Developer's Guide, superseding the extensions-related information that (in part) is already there in the current version of the Guide. Feel free to come back here with any questions along your way, -Stephan Also it seems, that deploying the extension will become really easy for the user, including updating the extension! Again, thank you very much! 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
Re: [dev] Class-Path Entry in Manifest Package File and the Location of the Respective jars?
[Changed the structure of the quoted mail so that my inline answers are in a logical order:] Rony G. Flatscher wrote: Hi there, for finalizing a package for bridging ooRexx with OOo (UNO) I was able to create a package that can be deployed successfully with unopkg add --shared ScriptProviderForooRexx.jar The scripting language is registered and shows up in the Macro menu. In order to ease installation and maintenance, I added the Class-Path: entry to the manifest files, denoting the jars needed to run. These jar-files were copied to OOoHome/program/classes (one DLL needed for Java and ooRexx, as well as supporting ooRexx scripts to OOoHome/program. The Class-Path entry in the manifest of a jar contains URLs for additional jars. If such a URL is relative (e.g., just bsf-rexx-engine.jar), then it is interpreted relative to the location of the jar (in the example, bsf-rexx-engine.jar would thus need to be located beside ScriptProviderForooRexx.jar). Jars that you put into OOo's program/classes directory are not automatically made available to the JVM, so that would not work. This is the manifest file (and the package registers successfully): Manifest-Version: 1.0 RegistrationClassName: com.sun.star.script.framework.provider.oorexx.S criptProviderForooRexx Class-Path: bsf-v242-20070128.jar bsf-rexx-engine.jar oorexx-uno.jar Created-By: ... Built-By: ... Name: org/oorexx/uno Specification-Title: ooRexx to/from UNO Bridge Specification-Version: 0.99 Specification-Vendor: ... Implementation-Title: org.oorexx.uno-via-bsf4rexx Implementation-Version: 0.99 Implementation-Vendor: ... Maybe it is something simple/stupid I am overseeing. Other than that I could create a mega-package adding the content of the other jars into this Scripting framework one. Yet another solution (which I have employed quite successfully) is to install the infrastructure-jars (which may be usabel in other Java applications) as a Java extension. If the three additional jars (bsf-v242-20070128.jar, bsf-rexx-engine.jar, oorexx-uno.jar) are only needed by ScriptProviderForooRexx.jar, create a ScriptProviderForooRexx.oxt extension (see http://api.openoffice.org/files/documents/22/3887/Extensions.pdf) instead that contains all four jars (and can also contain additional information like extension identifier, version, update information, see http://wiki.services.openoffice.org/wiki/Extensions_packaging). That way, your functionality (a script provider for ooRexx) comes as a self-contained entity (that can be deployed in one step via unopkg or OOo's Tools - Extension Manager...), without the need to add additional jars to special places (OOo's program/classes, JVM's extension path). It is on the extension wish list to have dependencies between extensions (so that you could for example have one extension that supplies bsf-v242-20070128.jar, bsf-rexx-engine.jar, oorexx-uno.jar, and another extension that depends on the first one so that it can use those three jars), but that is currently only a wish. just a small update to my little (still open!) question: copying the jar-files listed on Class-Path to the same directory the OOo package installer chose to install the jar file containing that Class-Path entry will allow to find those jar files. Yes, see above for why this would work. Now, if I knew upfront where the OOo package installer will put the jar, I could copy the other jars to that directory. But looking at the directory on Windows: D:\Programme\OpenOffice.org 2.1\share\uno_packages\cache\uno_packages\24.tmp_ looks as if that name could not be foreseen (24.tmp_ looks like an arbitrary name). Now, how about the relative depth of that directory (on both, Windows and Linux), would it be always on that level? If so, then I could reformulate the Class-Path-entry to read: Class-Path: ../../../../../program/classes/bsf-v242-20070128.jar ../.. /../../../program/classes/bsf-rexx-engine.jar ../../../../../program/ classes/oorexx-uno.jar Not looking nice, but serving its purpose (it works). But again: would the depth of the cached package directory remain and be the same on Linux? This is extremely fragile. Where exactly (including relative depth of path) extensions are stored is an implementation detail of OOo's extension manager that can easily change. Or do you think that packaging everything into one jar-file would be best? Not into one jar, but into one OOo extension, see above. Regards, ---rony -Stephan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Class-Path Entry in Manifest Package File and the Location of the Respective jars?
Hi Stephan, Rony, Stephan Bergmann a écrit : That way, your functionality (a script provider for ooRexx) comes as a self-contained entity (that can be deployed in one step via unopkg or OOo's Tools - Extension Manager...), without the need to add additional jars to special places (OOo's program/classes, JVM's extension path). This is already implemented in the Eclipse integration: the generated package will include the libraries contained in your project and added to the project classpath. Thus you don't have to know how to do it, simply use File Export Menu ;) I'll be pleased to answer questions on that topic if needed. Cedric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Class-Path Entry in Manifest Package File and the Location of the Respective jars?
Hi Stephan, thank you *very* much for your hints and pointers, which I need to follow and study in full in order to be able to experiment with it! (Will take some time, though.) If the three additional jars (bsf-v242-20070128.jar, bsf-rexx-engine.jar, oorexx-uno.jar) are only needed by ScriptProviderForooRexx.jar, create a ScriptProviderForooRexx.oxt extension (see http://api.openoffice.org/files/documents/22/3887/Extensions.pdf) instead that contains all four jars (and can also contain additional information like extension identifier, version, update information, see http://wiki.services.openoffice.org/wiki/Extensions_packaging). That way, your functionality (a script provider for ooRexx) comes as a self-contained entity (that can be deployed in one step via unopkg or OOo's Tools - Extension Manager...), without the need to add additional jars to special places (OOo's program/classes, JVM's extension path). That sounds exactly what I have been looking for (in addition I will have to supply platform dependent DLLs/so platforms and supportive - platform independent - scripts), could glimpse over it already a bit and saw that link libraries can be bundled for different platforms. Also it seems, that deploying the extension will become really easy for the user, including updating the extension! Again, thank you very much! Regards, ---rony - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Class-Path Entry in Manifest Package File and the Location of the Respective jars?
Bonsoir Cedric, Stephan Bergmann a écrit : That way, your functionality (a script provider for ooRexx) comes as a self-contained entity (that can be deployed in one step via unopkg or OOo's Tools - Extension Manager...), without the need to add additional jars to special places (OOo's program/classes, JVM's extension path). This is already implemented in the Eclipse integration: the generated package will include the libraries contained in your project and added to the project classpath. Thus you don't have to know how to do it, simply use File Export Menu ;) I'll be pleased to answer questions on that topic if needed. Thank you very much for your kind offer! Will definitely look into this Eclipse plugin (and congratulations for having it now in the Eclipse Central Plugin repository)! Though it will take some time, as I would like to study the needed setup for extension packages by hand and experiment with it (in order to really understand the framework and its ramifications). Once that is in place, I really would like to get to learn and to know your Eclipse plugin and what it can do to help free up development and maintenance time! :) Regards, ---rony - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] Class-Path Entry in Manifest Package File and the Location of the Respective jars?
Hi there, for finalizing a package for bridging ooRexx with OOo (UNO) I was able to create a package that can be deployed successfully with unopkg add --shared ScriptProviderForooRexx.jar The scripting language is registered and shows up in the Macro menu. In order to ease installation and maintenance, I added the Class-Path: entry to the manifest files, denoting the jars needed to run. These jar-files were copied to OOoHome/program/classes (one DLL needed for Java and ooRexx, as well as supporting ooRexx scripts to OOoHome/program. This is the manifest file (and the package registers successfully): Manifest-Version: 1.0 RegistrationClassName: com.sun.star.script.framework.provider.oorexx.S criptProviderForooRexx Class-Path: bsf-v242-20070128.jar bsf-rexx-engine.jar oorexx-uno.jar Created-By: ... Built-By: ... Name: org/oorexx/uno Specification-Title: ooRexx to/from UNO Bridge Specification-Version: 0.99 Specification-Vendor: ... Implementation-Title: org.oorexx.uno-via-bsf4rexx Implementation-Version: 0.99 Implementation-Vendor: ... Maybe it is something simple/stupid I am overseeing. Other than that I could create a mega-package adding the content of the other jars into this Scripting framework one. Yet another solution (which I have employed quite successfully) is to install the infrastructure-jars (which may be usabel in other Java applications) as a Java extension. Thankful again for any hints... ---rony
Re: [dev] Class-Path Entry in Manifest Package File and the Location of the Respective jars?
Hi there, just a small update to my little (still open!) question: copying the jar-files listed on Class-Path to the same directory the OOo package installer chose to install the jar file containing that Class-Path entry will allow to find those jar files. Now, if I knew upfront where the OOo package installer will put the jar, I could copy the other jars to that directory. But looking at the directory on Windows: D:\Programme\OpenOffice.org 2.1\share\uno_packages\cache\uno_packages\24.tmp_ looks as if that name could not be foreseen (24.tmp_ looks like an arbitrary name). Now, how about the relative depth of that directory (on both, Windows and Linux), would it be always on that level? If so, then I could reformulate the Class-Path-entry to read: Class-Path: ../../../../../program/classes/bsf-v242-20070128.jar ../.. /../../../program/classes/bsf-rexx-engine.jar ../../../../../program/ classes/oorexx-uno.jar Not looking nice, but serving its purpose (it works). But again: would the depth of the cached package directory remain and be the same on Linux? Or do you think that packaging everything into one jar-file would be best? Regards, ---rony Rony G. Flatscher wrote: Hi there, for finalizing a package for bridging ooRexx with OOo (UNO) I was able to create a package that can be deployed successfully with unopkg add --shared ScriptProviderForooRexx.jar The scripting language is registered and shows up in the Macro menu. In order to ease installation and maintenance, I added the Class-Path: entry to the manifest files, denoting the jars needed to run. These jar-files were copied to OOoHome/program/classes (one DLL needed for Java and ooRexx, as well as supporting ooRexx scripts to OOoHome/program. This is the manifest file (and the package registers successfully): Manifest-Version: 1.0 RegistrationClassName: com.sun.star.script.framework.provider.oorexx.S criptProviderForooRexx Class-Path: bsf-v242-20070128.jar bsf-rexx-engine.jar oorexx-uno.jar Created-By: ... Built-By: ... Name: org/oorexx/uno Specification-Title: ooRexx to/from UNO Bridge Specification-Version: 0.99 Specification-Vendor: ... Implementation-Title: org.oorexx.uno-via-bsf4rexx Implementation-Version: 0.99 Implementation-Vendor: ... Maybe it is something simple/stupid I am overseeing. Other than that I could create a mega-package adding the content of the other jars into this Scripting framework one. Yet another solution (which I have employed quite successfully) is to install the infrastructure-jars (which may be usabel in other Java applications) as a Java extension. Thankful again for any hints... ---rony
