Hi Karl,
Karl Weber wrote:
Hallo Steffen,
thanks for your answer. See my comments in-line -- as well...
Am Sonntag, 7. Juni 2009 00:02 schrieb Steffen Grund:
[...]
Although the NB plug-in does have a similar functionality, I am no longer
sure, whether it makes sense at all.
The reason is that the export wizard and the launch configuration depend
on the loader mechanism, i.e. on starting the main method of
com.sun.star.lib.loader.Loader which then starts the client application.
I am not sure, whether this is just some tooling to help a beginner to
get started and experiment with API functionality. If this were right, it
would not make sense to include support for java client applications into
the plug-in. At least not if it depends on this loader mechanism.
Well, the loader is definitely not some tooling just for beginners. It
makes client applications portable and removes the need of starting
OpenOffice.org for the user of the client.
Does it really remove the need to _start_ OpenOffice.org? As far as I looked
yes, it does and that is for most client applications a nice advantage.
at the source code, the Loader tries to find the paths for the necessary
files, enhances the classpath correspondingly and creates a new ClassLoader,
using this enhanced classpath.
The whole code is combination of the glue code coming with the SDK and
some other bootstrap code that is already in the office. The glue code
in the SDK indeed prepares a Java runtime env to call the other code ...
You can believe that the office starts automatically or if not you can
simply try it ;-)
OpenOffice.org is started by the Bootstrap class, which is independent of the
Loader... Or am I wrong here?
no you are not wrong, see above
If it does make sense to support java client applications, I would like
to know a little bit more about it, in particular:
- What should its functionality be?
I cannot really answer this, since I am not familiar with Eclipse. I try
my best to describe the way this works in NetBeans. But I really think I
should answer the following question first:
- Should it include the loader mechanism?
Yes, I think so. The benefit of the loader mechanism is that the newest
version of OpenOffice.org is located on the user's machine, independent
of the platform - the loader always includes algorithms to find
The newest version? Hmm... I doubt that -- at least as far as non-Windows OSes
are concerned. I don't know, how the Windows registry is searched.
First, some PATH-Variables are analysed (java property
com.sun.star.lib.loader.unopath, Environment UNO_PATH). (If I set a 'path', I
do not seem to need the Loader at all, see below.)
The ...loader.unopath is used to overload the default mechanism.
Sometimes it can be useful to start a specific office installation. But
often it is enough to start the default configured office.
Then on non-Windows PATH is analysed, then the which-command is tried. I am
not sure, whether this will always find the newest version....
yes but nobody said that the code will find and start the newest office.
On windows it is normally the last installed office because of the
registry entries. On Unix systems we don't have a registry and the
office is installed in different places on different systems. That means
it is not easy to find the default office automatically. The vanilla
build of OpenOffice creates for example a symbolic link in
/usr/bin/soffice -> /opt/openopffice.org3/program/soffice.
With this link we can find an office and in a lot of cases it is the
default office. If somebody has a better idea we are open to improve the
code here ;-)
Finally, .sversionrc is consulted.
OpenOffice.org for all platforms (well, Linux, Solaris, Windows, Mac).
Additionally, the Uno environment on the client application side is
taken dynamically from the OpenOffice.org version that is found by the
loader mechanism.
What, if the client wants to contact a remote OpenOffice.org? The Loader may
not find an OpenOffice.org on the local machine at all... But I don't know
whether a remote OpenOffice.org is used often in practise...
That doesn't work with this bootstrap code. There are examples in the
SDK how to bootrap an UNO env snd how to setup a remote connection ...
Anyway, in this case, it should be enough to put the required jar archives
somewhere on the local machine and add them to the classpath.
This can be done in any case, and, thus, the Loader does not seem to be
necessary. And this is OS-independent.
of course it could but that was exactly what we tried to prevent. We
would like to reuse the jars that are coming with the office to prevent
potential incompatible changes.
With this, you do not have to start the Office
yourself,
see my remark on the Bootstrap class above.
you can let the client do that. (If you want to work with a
definite version of OpenOffice.org, there are several ways to do so e.g
set the UNO_PATH environment variable or set the Java property
com.sun.star.lib.loader.unopath). This removes the need to pack the
OpenOffice.org jars (jurt, juh, etc.) into the client application. But
all this references on the usage of the client application standalone,
without IDE.
[...]
Hope that helps a little bit.
To sumarise, using the Loader, I do not seem to have to specify the location
of the necessary jar-files on the classpath, it will find them -- at least if
there is an OOo installation on the local machine. -- As far as I understand
it.
If I am right, I am even less sure about the usefulness/necessity of the
Loader.
mmh, i think it is not so tricky. Don't think about the development time
and the knowledge you have. When you include the bootstrap glue code
you don't have to care about a runtime environment later on. You can
simply deploy such a client application and potential users don't need
to know which office they use or what they have to prepare. They can
simply use the client app.
So what should I do now?
Well, it does make sense to finish the java client support for the ooeclipse
plug-in. The question is -- still -- whether the export wizard and the
run/debug configurations should include the Loader. Is your answer
still 'yes'?
yes, you should do it in the same way as the SDK or the NetBeans plugin
to make it equal. Everything else would confuse our users and wouldn't
be really helpful from my point of view.
One of the main ideas behind the different plugins for NB and Eclipse
was to provide an equal tooling for the two most often used Java IDE's.
Using the uno-skeletonmaker for example produce always the same code
independent of the used IDE.
Juergen
-Karl
---------------------------------------------------------------------
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]
