[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]
