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]

Reply via email to