Hi Jim,
thanks for your comments!
You should double check the file name & path. The JAR file is
"ScriptFramework.jar". And the path is relative to your JAR.
So if your JAR file is in a directory other than <OOo App>/.../classes
where ScriptFramework.jar is located, then I would suggest copying
ScriptFramework.jar into the one where you put your JAR.
Well, either locations, the same error pops up.
As DEV300 has changed the configuration and not being able to find
any related hints/infos, I hope that someone on this list may be able
to help to come by this situation.
That the classpath handling of com/sun/star/script/framework/* has
changed yet again makes me happy that I simply eliminated dependence
on it for GroovyForOpenOffice and as a result my extension works for
all OOo 2.* and 3.0. It seems a bit wasteful to duplicate those
classes, but it is clear that the OOo developers are treating them as
internal to OOo (which is what Juergen said last year when this came
up with 2.3).
Hmm. If interested in adding new scripting languages, then by all means
these classes cannot be regarded to be "internal use only". Also, there
is no flagging/warning not to use these classes. As a matter of fact,
without the ScriptMetaData class one would not be able to fetch the
script's code at all.
My speculation is that due to configuration and class loader changes
there are a few corners where currently we hit bugs or holes. Sometimes,
if those in the know can think of a reason why currently it does not
work, then one was able to come by the problem one way or the other,
hoping that the GA version would take care of this. (However, should I
file an issue for problems like this or not?)
[One interesting hint I got in earlier versions of DEV300 was that the
path to the executable soffice needs to be put on CLASSPATH. Later, when
experimenting with OOo 2.4.1 on Linux the bootstrapping did not work
there; having learned from DEV300 that CLASSPATH may be used by the
bootstrapper, I added it and it worked! Without the DEV300 hint I would
have *never* been able to try that out, because I would not have thought
about such a possibility.]
http://www.nabble.com/Re%3A-Script-framework%3A-docs-IDL-for-%22com.sun.star.script.framework%22---p12858342.html
This is also very interesting that essentially copying the OOo scripting
framework and refactoring all the packages will yield a script provider
that would *not* have troubles with 2.x and 3.x! Of course, you are
right, that one should not be forced to do that, as any time there are
bug fixes or enhancements on the OOo scripting framework one would need
to rebuild the own branch.
---
Now, maybe someone in here knows where Java- and scripting
framework-related issues are discussed and decided upon, before they get
implemented: e.g. Java base version to use, honoring CLASSPATH (at the
moment this is unfortunately *not* honored), the OOo class loaders,
their strategies and implementations, and the like.
Certainly, I have not seen any of this discussed in this list (nor at
api or dev), nor know of URLs where these points are documented for the
GA and for the beta versions.
---rony
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
