Hi,
as Stepahn has already mentioned, the new "Simple Bootstrap" mechanism is easy to use and does probably fulfill your requirements (see SDK exmaples).
I would prefer this way and wouldn't ship the OOo jar files with my own application. Your application depends probably on OOo and it does not make sense without. So if the bootstrap mechanism fails you can directly inform your user or can do something else.
Using the jars from the office installation has the benefit that you will always use the right ones.
- Juergen
Stephan Bergmann wrote:
Mike Traum wrote:
I'm developing an external, command-line java application that interfaces with oo 2.0. I'd prefer to bundle the oo jar's I use (juh.jar, jurt.jar, ridl.jar, unoil.jar) so that I don't have to deal with trying to find the location of the user's openoffice installation to set the classpath.
Is this an acceptable way of doing this, or will the api change so that every time a new OO point release comes out, I'm going to have to repackage my application.
Your approach should work (as long as you use those jars in compliance with their license, which shouldn't be much of a problem for LGPL), as we try to keep UNO backward compatible. (You won't benefit from any improvements, of course.)
However, a simple solution to locate and connect to an OOo instance is now available as "Simple Bootstrap," check out <http://udk.openoffice.org/common/man/spec/transparentofficecomponents.html>.
-Stephan
Thanks, Mike
--------------------------------------------------------------------- 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]
