Hello Karl,
see my comments inline...
Karl Weber schrieb:
Am Mittwoch, 25. März 2009 14:04 schrieb Juergen Schmidt:
[...]
browse the code and debug the examples directly from NetBeans. The
removed examples (in the original structure) can be stored for potential
use. Well the idea still is to provide the examples as Eclipse projects
as well,
I know, I volunteered.... :-)
The reason I didn't start yet is that the current functionality of the eclipse
plug-in does not really fit. Ariel said, most of the examples are Java Client
applications, not UNO components. Currently the eclipse plug-in does not
support Java Client applications, only UNO components and URE applications.
So I started to enhance the eclipse plug-in to support Java Client
applications. I thought it is better to do this first. Currently the new
functionality comprises
- a Java Client Application New Project Wizard
- a Java Client Application Export Wizard
- an additional Tab for the Java Client Application Project Properties page
- a run/debug launch configuration and a launch configuration short-cut
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.
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
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. With this, you do not have to start the Office
yourself, 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.
- If yes:
- - Will teh Loader remain part of the sdk?
As far as I know, nothig else is planned.
- - Will the Loader always be found in
<sdk-install-dir>/openoffice.org/basis3.1/sdk/classes/?
Well, yes, if you mean the basis-link directory which in OOo 3.1 points
to the above (and to basis3.2 in the next version).
Otherwise one would have to include the Loader source code into each
sdk-example and not have client application support in the plug-ins.
Or what would be the propper solution?
-Karl
So here's what we did in NetBeans: the result of a build of the client
application is a portable jar, including the loader machanism, but
nothing else. The client itself is executable, looking for
OpenOffice.org on the user's machine and starts it if it does not
already run.
Inside NetBeans, there's a different story. We assume that the user
wants to test or debug the client here. There are settings in NetBeans
that point to an OpenOffice.org version, so that version is started.
This may sound easy now, but it wasn't. We had to do some ant trickery,
due to the different class loaders used.
Hope that helps a little bit.
Regards, Steffen
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]