Info: potential SDK changes for OO.org 3.2

[Juergen Schmidt-3]

Hi,

the SDK contains many examples showing the usage of the API etc. The
examples got not really maintained and the workload for testing them is
  high.

Some time in the past i have already mentioned that the idea is to
remove some of the examples from the SDK. Mainly examples written in
Java that are now available as NetBeans projects and that can be used
instead. The advantage of the NetBeans projects is that you can easier
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, or as MSDEV projects converted to C++, or Python? Volunteers
are welcome!

A further advantage of having the examples standalone and documented in
the wiki is that the community can easier help to improve the examples.
you can comment them on the related discussion page, can improve the
code or the documentation etc. We now have enough experienced API users
that can help in this area ;-)

Anyway nothing is decided yet and the SDK build system will remain in
the SDK independent of the examples. That means your own solutions based
on the SDK build env will still work.

The main reason for this email is that i would like to ask if somebody
has concerns about this planned change. If so please let me know and let
us continue further discussion on dev@....

By the way QA volunteers for the SDK examples or the SDK in general are
welcome. If you are interested to help in this area please let me know.

Regards

Juergen

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Ariel Constenla-Haile]

Hello Juergen,

On Wednesday 25 March 2009, 10:04, Juergen Schmidt wrote:

> Hi,
>
> the SDK contains many examples showing the usage of the API etc. The
> examples got not really maintained and the workload for testing them is
>   high.
>
> Some time in the past i have already mentioned that the idea is to
> remove some of the examples from the SDK. Mainly examples written in
> Java that are now available as NetBeans projects and that can be used
> instead. The advantage of the NetBeans projects is that you can easier
> browse the code and debug the examples directly from NetBeans.

Karl Weber's arguments convinced me that it is better to have the Java sources
independent from the NetBeans project: this way, instead of having to maintain
the sources for NB, Eclipse, etc., the only sources that have to maintained
are the project-independent ones; then one has the way how to include this
sources in the respective project.

For client applications, NB with the OOo API plugin can have relative sources,
so that the NB user only needs to get (and keep together, otherwise the
relative reference does not work)

api/examples/java/sources
api/examples/java/netbeans

For UNO components, relative references do not work because the plugin has
several issues (the extension manifest, IDL files, etc. must be inside the
project). I can't imagine a good solution with cvs, but svn has external
definitions (though OOo is planning to move away from svn...)

Another

> A further advantage of having the examples standalone and documented in
> the wiki is that the community can easier help to improve the examples.

submiting code may not require write access to the repository, it can be
submited via issue tracker; but wouldn't anyway this mean to sign the JCA? ...
not so easy in this case...

Regards
--
Ariel Constenla-Haile
La Plata, Argentina


"Aus der Kriegsschule des Lebens
        - Was mich nicht umbringt,
        macht mich härter."
        Nietzsche Götzendämmerung, Sprüche und Pfeile, 8.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Steffen Grund]

Hi Ariel,

Ariel Constenla-Haile wrote:

> Hello Juergen,
>
> On Wednesday 25 March 2009, 10:04, Juergen Schmidt wrote:
>> Hi,
>>
>> the SDK contains many examples showing the usage of the API etc. The
>> examples got not really maintained and the workload for testing them is
>>   high.
>>
>> Some time in the past i have already mentioned that the idea is to
>> remove some of the examples from the SDK. Mainly examples written in
>> Java that are now available as NetBeans projects and that can be used
>> instead. The advantage of the NetBeans projects is that you can easier
>> browse the code and debug the examples directly from NetBeans.
>
> Karl Weber's arguments convinced me that it is better to have the Java sources
> independent from the NetBeans project: this way, instead of having to maintain
> the sources for NB, Eclipse, etc., the only sources that have to maintained
> are the project-independent ones; then one has the way how to include this
> sources in the respective project.
>
> For client applications, NB with the OOo API plugin can have relative sources,
> so that the NB user only needs to get (and keep together, otherwise the
> relative reference does not work)
>
> api/examples/java/sources
> api/examples/java/netbeans
>
> For UNO components, relative references do not work because the plugin has
> several issues (the extension manifest, IDL files, etc. must be inside the
> project). I can't imagine a good solution with cvs, but svn has external
> definitions (though OOo is planning to move away from svn...)
>

You are right here concerning the place of important files (like idl
files, manifest etc.) for a UNO component used with the NetBeans plugin.
They have to be inside of the NetBeans project. Of course, this can be
fixed, but I do not know when I'd find the time for this.
Are there any volunteers wanting to help improve the NetBeans plugin for
OpenOffice.org?

-Steffen

> Another
>
>> A further advantage of having the examples standalone and documented in
>> the wiki is that the community can easier help to improve the examples.
>
> submiting code may not require write access to the repository, it can be
> submited via issue tracker; but wouldn't anyway this mean to sign the JCA? ...
> not so easy in this case...
>
> Regards

--
Steffen Grund <steffen.grund@...>                  Sun Microsystems
Software Engineer - StarOffice                             Nagelsweg 55
Phone:  [phone]                                D-20097 Hamburg
Fax:    [phone]                  http://www.sun.com/staroffice
-----------------------------------------------------------------------
Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1,
D-85551 Kirchheim-Heimstetten
Amtsgericht Muenchen: HRB 161028
Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Dr. Roland Boemer
Vorsitzender des Aufsichtsrates: Martin Haering

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Juergen Schmidt-3]

Ariel Constenla-Haile wrote:

> Hello Juergen,
>
> On Wednesday 25 March 2009, 10:04, Juergen Schmidt wrote:
>> Hi,
>>
>> the SDK contains many examples showing the usage of the API etc. The
>> examples got not really maintained and the workload for testing them is
>>   high.
>>
>> Some time in the past i have already mentioned that the idea is to
>> remove some of the examples from the SDK. Mainly examples written in
>> Java that are now available as NetBeans projects and that can be used
>> instead. The advantage of the NetBeans projects is that you can easier
>> browse the code and debug the examples directly from NetBeans.
>
> Karl Weber's arguments convinced me that it is better to have the Java sources
> independent from the NetBeans project: this way, instead of having to maintain
> the sources for NB, Eclipse, etc., the only sources that have to maintained
> are the project-independent ones; then one has the way how to include this
> sources in the respective project.
>
> For client applications, NB with the OOo API plugin can have relative sources,
> so that the NB user only needs to get (and keep together, otherwise the
> relative reference does not work)
>
> api/examples/java/sources
> api/examples/java/netbeans
>
> For UNO components, relative references do not work because the plugin has
> several issues (the extension manifest, IDL files, etc. must be inside the
> project). I can't imagine a good solution with cvs, but svn has external
> definitions (though OOo is planning to move away from svn...)

i also like the idea to keep the code independent of a specific IDE. But
you pointed out that it is difficult for complete extensions (have to
analyzed in detail). We offer a good support for NetBeans and probably
for Eclipse exists a NetBeans project importer as vice versa in NB ;-)

It's only a minor overhead for the NB projects and people who are
interested in the code only can easy extract it. For the complete or
better complex examples you need to know what you have to do anyway and
it's not enough to have the code only...

I am flexible, if we can find an easy way to separate it i would be
happy to support it. But i have no time to investigate deeper in this
area. I am happy with the easy to use NB projects so far ;-)

The work needs to be done in some way!!!! If people volunteer to find a
better way and of course to do the work then it will be fine for me and
i will support it where i can.

For smaller examples we have still our code snippets ...


>
> Another
>
>> A further advantage of having the examples standalone and documented in
>> the wiki is that the community can easier help to improve the examples.
>
> submiting code may not require write access to the repository, it can be
> submited via issue tracker; but wouldn't anyway this mean to sign the JCA? ...
> not so easy in this case...
mmh, not sure but i would expect that people who are interested to help
have no problems with a JCA. But it is nothing new and i see no real
difference.

Juergen

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Karl Weber]

Hi,

Am Mittwoch, 25. März 2009 15:13 schrieb Juergen Schmidt:

> > For client applications, NB with the OOo API plugin can have relative
> > sources, so that the NB user only needs to get (and keep together,
> > otherwise the relative reference does not work)
> >
> > api/examples/java/sources
> > api/examples/java/netbeans
> >
> > For UNO components, relative references do not work because the plugin
> > has several issues (the extension manifest, IDL files, etc. must be
> > inside the project). I can't imagine a good solution with cvs, but svn
> > has external definitions (though OOo is planning to move away from
> > svn...)
>
> i also like the idea to keep the code independent of a specific IDE. But
> you pointed out that it is difficult for complete extensions (have to
> analyzed in detail). We offer a good support for NetBeans and probably
> for Eclipse exists a NetBeans project importer as vice versa in NB ;-)
>
> It's only a minor overhead for the NB projects and people who are
> interested in the code only can easy extract it. For the complete or
> better complex examples you need to know what you have to do anyway and
> it's not enough to have the code only...
>
> I am flexible, if we can find an easy way to separate it i would be
> happy to support it. But i have no time to investigate deeper in this
> area. I am happy with the easy to use NB projects so far ;-)
>
> The work needs to be done in some way!!!! If people volunteer to find a
> better way and of course to do the work then it will be fine for me and
> i will support it where i can.

Some while ago I already volunteered to discuss the examples of the DevGuide
in the wiki. I postponed to start until April, since Ariel said some of the
examples have serious issues he wants to fix till then.

I still intend to do this, therefore I communicated with Ariel about
separating source from IDE-projects, so that only one source-version has to
be maintained. I would then provide Eclipse projects without source code.

The import of the source code seems to be quite simple for Eclipse. If the
directory-structure of the sources is appropriate, one can use a particular
target in a build-script of an Eclipse (and other IDE) project to
automatically download the source via CVS (or other) and include them into
the project. One may even make the "build" target dependent on this "download
and import the sources" target so that the user may not even notice it.

I think one needs to agree on only two things, in order to allow for a
flexible automatic download of the sources:

(1) Where are the sources (and projects) to be kept?

Should they be kept in the CVS, or other repository, or should they be put
directly in the wiki? The only constraint seems to be, that one should be
able to use ant to download the sources. (CVS and Get are build into ant, for
SVN one needs an additional ant library, as far as I understand.)

A related question is: where should the IDE-projects be kept? As zip files in
the wiki or in a repository?

If I remember right, the idea is that people should be able to add their own
examples, or add an example that is already present in another language. It
would be much easier to upload to the wiki. Not everybody has write access to
the CVS (or other repository).

(2) What is an appropriate source code structure?

In particular for UNO-IDL projects, the plugins for Eclipse and NB seem to
have some particular requirements here. Furthermore there is a Maven2
integration for OOo. Maven2 usually also requires some particular directory
structure.

If the source code structure is fine enough, every project should be able to
use an automatic download and import the sources to its own structure.

I would suggest something like the following:

src: source code (java or other).
res: other resources, like images, writer documents etc.
idl: for idl files.
win: for the unowinreg.dll

This should be fine grained enough -- for all I know.

-Karl
 






---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Juergen Schmidt-3]

Karl Weber wrote:

> Hi,
>
> Am Mittwoch, 25. März 2009 15:13 schrieb Juergen Schmidt:
>>> For client applications, NB with the OOo API plugin can have relative
>>> sources, so that the NB user only needs to get (and keep together,
>>> otherwise the relative reference does not work)
>>>
>>> api/examples/java/sources
>>> api/examples/java/netbeans
>>>
>>> For UNO components, relative references do not work because the plugin
>>> has several issues (the extension manifest, IDL files, etc. must be
>>> inside the project). I can't imagine a good solution with cvs, but svn
>>> has external definitions (though OOo is planning to move away from
>>> svn...)
>> i also like the idea to keep the code independent of a specific IDE. But
>> you pointed out that it is difficult for complete extensions (have to
>> analyzed in detail). We offer a good support for NetBeans and probably
>> for Eclipse exists a NetBeans project importer as vice versa in NB ;-)
>>
>> It's only a minor overhead for the NB projects and people who are
>> interested in the code only can easy extract it. For the complete or
>> better complex examples you need to know what you have to do anyway and
>> it's not enough to have the code only...
>>
>> I am flexible, if we can find an easy way to separate it i would be
>> happy to support it. But i have no time to investigate deeper in this
>> area. I am happy with the easy to use NB projects so far ;-)
>>
>> The work needs to be done in some way!!!! If people volunteer to find a
>> better way and of course to do the work then it will be fine for me and
>> i will support it where i can.
>
> Some while ago I already volunteered to discuss the examples of the DevGuide
> in the wiki. I postponed to start until April, since Ariel said some of the
> examples have serious issues he wants to fix till then.
>
> I still intend to do this, therefore I communicated with Ariel about
> separating source from IDE-projects, so that only one source-version has to
> be maintained. I would then provide Eclipse projects without source code.

that's fine and good to know. I would suggest that we discuss everything
on the mailing list to involve more people.

>
> The import of the source code seems to be quite simple for Eclipse. If the
> directory-structure of the sources is appropriate, one can use a particular
> target in a build-script of an Eclipse (and other IDE) project to
> automatically download the source via CVS (or other) and include them into
> the project. One may even make the "build" target dependent on this "download
> and import the sources" target so that the user may not even notice it.
well of course that is possible but do we really need it? Or would it be
enough to have combined zips (source  + project files) for the different
IDEs. In case of Java i assume that it would be fine to have a NB,
Eclipse and source only package.

To keep it simple i would prefer a simple zip package containing
everything i need (ok no SDK and no office) to build and use the
example. No further dependencies as a working network etc.

>
> I think one needs to agree on only two things, in order to allow for a
> flexible automatic download of the sources:
>
> (1) Where are the sources (and projects) to be kept?
>
> Should they be kept in the CVS, or other repository, or should they be put
> directly in the wiki? The only constraint seems to be, that one should be
> able to use ant to download the sources. (CVS and Get are build into ant, for
> SVN one needs an additional ant library, as far as I understand.)

i would like to see it in a scm (whatever will be used in the future). I
think the advantages of a scm are obvious. Most people want simply use
the examples, i expect only a minor group who will contribute new
examples or will change existing ones. The people who are interested can
easy get the necessary rights for the scm.

>
> A related question is: where should the IDE-projects be kept? As zip files in
> the wiki or in a repository?
i think both, we should have everything in a scm and should build the
zips automatically. After a short QA of the zips we can provide them for
download. I think it's important that we separate the QA'ed examples
from the working code where potentially somebody works on improvements.

>
> If I remember right, the idea is that people should be able to add their own
> examples, or add an example that is already present in another language. It
> would be much easier to upload to the wiki. Not everybody has write access to
> the CVS (or other repository).
Either people get the rights or if they don't want it for whatever
reason i volunteer to check in the examples for them ...

>
> (2) What is an appropriate source code structure?
>
> In particular for UNO-IDL projects, the plugins for Eclipse and NB seem to
> have some particular requirements here. Furthermore there is a Maven2
> integration for OOo. Maven2 usually also requires some particular directory
> structure.
>
> If the source code structure is fine enough, every project should be able to
> use an automatic download and import the sources to its own structure.
>
> I would suggest something like the following:
>
> src: source code (java or other).
> res: other resources, like images, writer documents etc.
> idl: for idl files.
> win: for the unowinreg.dll

the unowinreg.dll should be used from the SDK. We changed the NB plugin
accordingly.

In production projects we use today a structure like this:

src = source code (java, idl, others)
registry = xcs and xcu files. The config packages gives the directory
structure [1]
dialogs = xdl + related property files
images = images -> self explaining
help = help files (localized) in the required structure [2]
description = oxt description files (localized)

[1] It's important that the config files are stored in a directory
structure that is equal to the internal package to make use of automatic
localization features in the office build env. And we separate xcu and
xcs as in the office.

For example:
registry/data/org/openoffice/Office/Addons.xcu
registry/data/org/openoffice/MyConfig/Example.xcu
registry/schema/org/openoffice/MyConfig/Example.xcs

[2] Help files have to be stored in the oxt in a specific structure. We
do it directly in the projects.
help/<locale>/<oxt_identifier/**/*.xhp

For example:
help/en/org.openoffice.examples.Demo1/demohelp.xhp
help/en/org.openoffice.examples.Demo1/demo1a/demo1a.xhp
help/en/org.openoffice.examples.Demo1/demo1b/demo1b.xhp

NOTE that the xhp files can be stored in sub directories as well and of
course can be linked from each other ...

The advantage of doing it this way is that projects using this structure
can be easy integrated in the office build env. Especially config and
help files need this structure to make use of office localization
feature (extract strings into the related translation database and vice
versa)

One of the goals should be to bring developers to the project and to
contribute their work back.

Anyway the most important Java IDEs are probably Eclipse and NetBeans
and i think it would be possible to have both in the same zip file where
source and project files are clearly separated. The overhead of the
project specific files is probably minimal.

For our users it would be the easiest way to get and work with the
examples. Download or get it from a CD -> unzip -> open IDE of choice ->
open project -> build -> run or debug


Juergen



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Karl Weber]

Am Donnerstag, 26. März 2009 11:16 schrieb Juergen Schmidt:
> Karl Weber wrote:
> > Hi,
> >
[...]

> > Some while ago I already volunteered to discuss the examples of the
> > DevGuide in the wiki. I postponed to start until April, since Ariel said
> > some of the examples have serious issues he wants to fix till then.
> >
> > I still intend to do this, therefore I communicated with Ariel about
> > separating source from IDE-projects, so that only one source-version has
> > to be maintained. I would then provide Eclipse projects without source
> > code.
>
> that's fine and good to know. I would suggest that we discuss everything
> on the mailing list to involve more people.

Concerning the wiki there was already a discussion, first on
dev@documentation, continued at dev and finally continued at dev@api. I don't
know whether something has to be added to that -- but I will have to read the
mails again... Maybe I should start with FirstSteps and ask for opinions on
the list.

Concerning the Eclipse (IDE) projects I am not sure about the purpose. Is the
purpose only to provide an environment to browse and debug the code (for
client apps this is basically all...) and/or build a component or extension
with the help of the plugin?

In this case an Eclipse project does not need to contain anything but the
sources and an instruction about how to install and configure the plugin. No
ant build script would be necessary.

Or should it, e.g., also show how to create a client app, i.e., should it also
contain a build script to create a jar with all necessary ingredients
(unowinreg.dll, loader)? (The Eclipse plugin does not seem to support
building jars for client apps. Another way would be to enhance the plugin.)

Furthermore: How many projects should there be? One could make one project for
every chapter (FirstSteps, Professional UNO, ...) or one for all java
examples of the DevGuide, and create a java package for every chapter. (There
are 168 Java class files for the DevGuide examples) I would prefer one
project for every chapter of the DevGuide.

What about the source code of the libraries juh, jurt, ridl, and unoil -- and
the loader? In the following I will only refer to java, but it should apply
to other languages as well. Sure, one can download the whole source of the
SDK/OOo. But suppose someone wants to debug the examples, including the API,
in java. He/she only needs the java sources of the libs and the loader. Sure,
one can selectively download them from the repository as well, but this is
more work. Furthermore, not all sources are there. ridl.jar contains 28 class
files in com.sun.star.uno. In ridljar are only 13 java files. After building
OOO3 I can still not find the remaining 15 java files.

Furthermore, the libraries (juh, jurt, ridl, and unoil) seem to be built
without debug flag. So the debugger will not show local variables.

Hence it might be useful to provide debug versions of these libraries and the
java-source code so that people can easily debug the API.

One may try to add one project for every of the libraries (juh, jurt, ridl,
and unoil), if there are no other dependencies.

>
> > The import of the source code seems to be quite simple for Eclipse. If
> > the directory-structure of the sources is appropriate, one can use a
> > particular target in a build-script of an Eclipse (and other IDE) project
> > to automatically download the source via CVS (or other) and include them
> > into the project. One may even make the "build" target dependent on this
> > "download and import the sources" target so that the user may not even
> > notice it.
>
> well of course that is possible but do we really need it? Or would it be

If only empty shells of projects are provided and the source code has to be
imported, such an ant target would make things easier.....

> enough to have combined zips (source  + project files) for the different
> IDEs. In case of Java i assume that it would be fine to have a NB,
> Eclipse and source only package.
>

... or one could use this approach. I am no friend of keeping things
redundant, and since the source code would be kept redundant here, it would
not be my first choice. And what about debug versions of the jars and maybe
the java source? Should they also be kept redundant in every IDE project?

How do you enforce that every project uses identical source code?

And again: How many zip files should there be? If there is one project for
every chapter in the DevGuide, is there also one zip file for every chapter,
or one zip file for all java examples of the DevGuide?

> To keep it simple i would prefer a simple zip package containing
> everything i need (ok no SDK and no office) to build and use the
> example. No further dependencies as a working network etc.
>
> > I think one needs to agree on only two things, in order to allow for a
> > flexible automatic download of the sources:
> >
> > (1) Where are the sources (and projects) to be kept?
> >
> > Should they be kept in the CVS, or other repository, or should they be
> > put directly in the wiki? The only constraint seems to be, that one
> > should be able to use ant to download the sources. (CVS and Get are build
> > into ant, for SVN one needs an additional ant library, as far as I
> > understand.)
>
> i would like to see it in a scm (whatever will be used in the future). I
> think the advantages of a scm are obvious. Most people want simply use
> the examples, i expect only a minor group who will contribute new
> examples or will change existing ones. The people who are interested can
> easy get the necessary rights for the scm.
>
> > A related question is: where should the IDE-projects be kept? As zip
> > files in the wiki or in a repository?
>
> i think both, we should have everything in a scm and should build the
> zips automatically. After a short QA of the zips we can provide them for
> download. I think it's important that we separate the QA'ed examples
> from the working code where potentially somebody works on improvements.
>
> > If I remember right, the idea is that people should be able to add their
> > own examples, or add an example that is already present in another
> > language. It would be much easier to upload to the wiki. Not everybody
> > has write access to the CVS (or other repository).
>
> Either people get the rights or if they don't want it for whatever
> reason i volunteer to check in the examples for them ...

This means, I would create an Eclipse project for the FirstSteps (to start
with) and send it to you by mail. You would (test it and) check it in. Then a
ZIP with a corresponding NB project and a source code only version would be
created. After it has been QA'ed I could upload the zip file into the wiki
and in addition provide a link to the repository and maybe to the source code
files...?

>
> > (2) What is an appropriate source code structure?
> >
> > In particular for UNO-IDL projects, the plugins for Eclipse and NB seem
> > to have some particular requirements here. Furthermore there is a Maven2
> > integration for OOo. Maven2 usually also requires some particular
> > directory structure.
> >
> > If the source code structure is fine enough, every project should be able
> > to use an automatic download and import the sources to its own structure.
> >
> > I would suggest something like the following:
> >
> > src: source code (java or other).
> > res: other resources, like images, writer documents etc.
> > idl: for idl files.
> > win: for the unowinreg.dll
>
> the unowinreg.dll should be used from the SDK. We changed the NB plugin
> accordingly.
>
> In production projects we use today a structure like this:
>
> src = source code (java, idl, others)

Hmm.... Does this mean, the structure is

src/java: for java source code
src/idl: for IDL files
src/res: for other?

I don't like this as much as src, idl, and res, as suggested. It doen't look
that nice in Eclipse. One flaw, however, might be fixed in the plugin...

However, if the source code is kept redundant in every IDE project, why cannot
every IDE project adapt the directory structure to some extend?

-Karl

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Juergen Schmidt-3]

Karl Weber wrote:

> Am Donnerstag, 26. März 2009 11:16 schrieb Juergen Schmidt:
>> Karl Weber wrote:
>>> Hi,
>>>
> [...]
>
> Concerning the wiki there was already a discussion, first on
> dev@documentation, continued at dev and finally continued at dev@api. I don't
> know whether something has to be added to that -- but I will have to read the
> mails again... Maybe I should start with FirstSteps and ask for opinions on
> the list.
>
> Concerning the Eclipse (IDE) projects I am not sure about the purpose. Is the
> purpose only to provide an environment to browse and debug the code (for
> client apps this is basically all...) and/or build a component or extension
> with the help of the plugin?

Browsing the code is a minor advantage but often IDEs provide some nice
features (class views, ...) Debugging the code, the example is much more
important. Walking through the code step by step and seeing what
happens. I think that can help a lot to understand the API and the
examples.

>
> In this case an Eclipse project does not need to contain anything but the
> sources and an instruction about how to install and configure the plugin. No
> ant build script would be necessary.
>
> Or should it, e.g., also show how to create a client app, i.e., should it also
> contain a build script to create a jar with all necessary ingredients
> (unowinreg.dll, loader)? (The Eclipse plugin does not seem to support
> building jars for client apps. Another way would be to enhance the plugin.)
well what else could be interesting for client apps. People probably
want to learn how they can create a client app what the essential parts.

>
> Furthermore: How many projects should there be? One could make one project for
> every chapter (FirstSteps, Professional UNO, ...) or one for all java
> examples of the DevGuide, and create a java package for every chapter. (There
> are 168 Java class files for the DevGuide examples) I would prefer one
> project for every chapter of the DevGuide.
In one big projects the user probably get lost. I think Ariel has
already started with one project for one chapter and different run
options for the different examples

>
> What about the source code of the libraries juh, jurt, ridl, and unoil -- and
> the loader? In the following I will only refer to java, but it should apply
> to other languages as well. Sure, one can download the whole source of the
> SDK/OOo. But suppose someone wants to debug the examples, including the API,
> in java. He/she only needs the java sources of the libs and the loader. Sure,
> one can selectively download them from the repository as well, but this is
> more work. Furthermore, not all sources are there. ridl.jar contains 28 class
> files in com.sun.star.uno. In ridljar are only 13 java files. After building
> OOO3 I can still not find the remaining 15 java files.
>
> Furthermore, the libraries (juh, jurt, ridl, and unoil) seem to be built
> without debug flag. So the debugger will not show local variables.
>
> Hence it might be useful to provide debug versions of these libraries and the
> java-source code so that people can easily debug the API.

yes i agree and that are good points but i would keep this separately.

>
> One may try to add one project for every of the libraries (juh, jurt, ridl,
> and unoil), if there are no other dependencies.
well it is probably not so easy to separate it from the oo build env.
Maybe we can try it but i would first focus on the real SDK parts.
Everything else would be possible to use the OO sources, rebuild the
related sources and use exchange the jars. I agree that it is not
comfortable but it is as it is at the moment.

>> well of course that is possible but do we really need it? Or would it be
>
> If only empty shells of projects are provided and the source code has to be
> imported, such an ant target would make things easier.....
>
>> enough to have combined zips (source  + project files) for the different
>> IDEs. In case of Java i assume that it would be fine to have a NB,
>> Eclipse and source only package.
>>
>
> ... or one could use this approach. I am no friend of keeping things
> redundant, and since the source code would be kept redundant here, it would
> not be my first choice. And what about debug versions of the jars and maybe
> the java source? Should they also be kept redundant in every IDE project?

see it from a user perspective. You would deal only with the zip files
that are qa'ed and where it is guaranteed that they work with the
related office/SDK version.

The zips are more or less the released versions of the examples. You can
call it redundant but i think it is a little bit different. We have
Basic/Python/JavaScript example macros in the office and in the code
repository. Is it also redundant?

Our "product" are example projects and they contain code. That's fine
and we release snapshots.

>
> How do you enforce that every project uses identical source code?
i am not sure what do you mean here

>
> And again: How many zip files should there be? If there is one project for
> every chapter in the DevGuide, is there also one zip file for every chapter,
> or one zip file for all java examples of the DevGuide?
one zip per chapter

[...]

>>> If I remember right, the idea is that people should be able to add their
>>> own examples, or add an example that is already present in another
>>> language. It would be much easier to upload to the wiki. Not everybody
>>> has write access to the CVS (or other repository).
>> Either people get the rights or if they don't want it for whatever
>> reason i volunteer to check in the examples for them ...
>
> This means, I would create an Eclipse project for the FirstSteps (to start
> with) and send it to you by mail. You would (test it and) check it in. Then a
> ZIP with a corresponding NB project and a source code only version would be
> created. After it has been QA'ed I could upload the zip file into the wiki
> and in addition provide a link to the repository and maybe to the source code
> files...?

mmh, not sure if it would be exactly this way. It should be the
exception. But i would take the existing NB project and would use the
source form there to create an Eclipse project in the same directory or
a sub directory. The NB project files would be also moved into a sub
directory if necessary. But that depends if and how NB and Eclipse
projects can coexist side by side.

>
>>> (2) What is an appropriate source code structure?
>>>
>>> In particular for UNO-IDL projects, the plugins for Eclipse and NB seem
>>> to have some particular requirements here. Furthermore there is a Maven2
>>> integration for OOo. Maven2 usually also requires some particular
>>> directory structure.
>>>
>>> If the source code structure is fine enough, every project should be able
>>> to use an automatic download and import the sources to its own structure.
>>>
>>> I would suggest something like the following:
>>>
>>> src: source code (java or other).
>>> res: other resources, like images, writer documents etc.
>>> idl: for idl files.
>>> win: for the unowinreg.dll
>> the unowinreg.dll should be used from the SDK. We changed the NB plugin
>> accordingly.
>>
>> In production projects we use today a structure like this:
>>
>> src = source code (java, idl, others)
>
> Hmm.... Does this mean, the structure is
>
> src/java: for java source code
> src/idl: for IDL files
> src/res: for other?

no, src contains java and idl in the same directories

>
> I don't like this as much as src, idl, and res, as suggested. It doen't look
> that nice in Eclipse. One flaw, however, might be fixed in the plugin...
>
> However, if the source code is kept redundant in every IDE project, why cannot
> every IDE project adapt the directory structure to some extend?
we can do it. I already suggested to put everything in the same
directory because the overhead for IDE project files is minimal. The
point is that we have to do much more. The NB plugin is as it is at the
moment but it helps quite well to speed up development of new projects
and to work with existing ones. So i would really like to keep the
structure supported by the plugin because i think it helps the users a lot.

Steffen mentioned already that we can adapt the NB plugin to allow more
flexibility with the project structures. But that has to be done for NB
and probably for Eclipse.

Ariel has already done a good job to provide the NB examples. If we now
can start to put the Eclipse project files in the same projects in a sub
directory to keep it separated from the NB files then we are on a good
way. We share the source files and every other necessary files, and can
build with NB and Eclipse. Others who interested in the code only can
ignore the IDE specific files.

Juergen

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Ariel Constenla-Haile]

Hello Juergen, Karl, *

[instead of answering every individual mail, I collect here my opinions.]

* all code should be on a respository, this is better for development. Sources
can be tagged and for every OOo release zip files can be generated for the API
end-user

* Java sources and IDE's projects should be separeted on the respository; the
projects should be only "skeletons", only containing project files; java
sources should contain the sources and all common files (resources, config.
files, etc.) This is the better way to maintain *only*  a set of sources and
not one for every project type.

* for the API end-user, the zipped projects should contain ready-to-user
projects: no separated sources, no need to download anything else.
This not only for the ease-of-use (relative sources may be confusing), but
also becuase NB plugin (and Eclipse) does not support relative sources for UNO
components.

This means:

* the packager zipping the projects will have to find a way to put all the
separated sources inside the respective project

* the developers working on the source code and the projects development, will
have to find a way to design the projects so that they are configured as if the
sources where inside the projects (otherwise the projects won't work for the
end-user).

In Linux I've found the solution for the later using symbolic links: NB treats
the sources as if they where inside the project, cvs does not mess with the
symlinks (don't know how portable this is to other plataforms...)

For the packaging problem, I think the solution is in the repository design:
with a structure like the following:

/api/examples/java/sources/$TYPE/$EXAMPLE_NAME
/api/examples/java/$IDE/$TYPE/$EXAMPLE_NAME

for example

/api/examples/java/sources/text/DevGuideTextDocumentExamples
/api/examples/java/netbeans/text/DevGuideTextDocumentExamples
/api/examples/java/eclipse/text/DevGuideTextDocumentExamples

is very easy to write a script to copy everything from
/api/examples/java/sources/$TYPE/$EXAMPLE_NAME to
/api/examples/java/$IDE/$TYPE/$EXAMPLE_NAME

and while copying, the script can rename according to the respective IDE
requisites; for example, the extension manifest must be named
"uno-extension-manifest.xml" for the NB plug-in, ...

-------------------------------------------------------------------------------------


Another point for better maintenance is separating what's common in every
sources: for UNO components, the component loader/registration code; for
client applications, the installation finder and class loader code.

Something like the following could work:

/examples/java/source/common

with two folders

clientapp
unocomp

mmm...well about the later I'm not so sure, because the component registration
code is different in NB plugin and Eclipse plugin, so they could also be in

/api/examples/java/$IDE/common/unocomp


-------------------------------------------------------------------------------------

Concerning the repository (and final zip) structure, I propose to group by
application, where possible, and in the other cases follow the respective
Dev's Guide chapter. For example:

examples/java/source|$IDE/writer
examples/java/source|$IDE/calc
examples/java/source|$IDE/drawing
examples/java/source|$IDE/database
examples/java/source|$IDE/chart
examples/java/source|$IDE/math

not applications, but forming a closed group are

examples/java/source|$IDE/forms
examples/java/source|$IDE/ucb
examples/java/source|$IDE/configuration
examples/java/source|$IDE/gui

the rest follow the Dev's Guide chapters

examples/java/source|$IDE/FirstSteps
examples/java/source|$IDE/ProfUno
examples/java/source|$IDE/Components
examples/java/source|$IDE/OfficeDev
examples/java/source|$IDE/ScriptingFramework


-----------------------------------------------------------------------------------

Concerning how many projects we should make out of the examples, IMHO one
project for client appl. with a class with main method is a non-sense.

So I'd vote for grouping, where possible, the client appications in only one
project/JAR.

For example, all client apps. in
/opt/openoffice.org/basis3.1/sdk/examples/DevelopersGuide/Spreadsheet

grouped in
examples/java/source|$IDE/calc/DevGuideSpreadsheetExamples

all client apps. in /opt/openoffice.org/basis3.1/sdk/examples/java/Spreadsheet

grouped in
examples/java/source|$IDE/calc/SDKJavaSpreadsheetExamples


In the future, new examples could be grouped in new projects, or in its own
project, but for the existing examples this way makes clear where the example
comes from (from the Dev's Guide, or from sdk/examples/java)

For UNO components, of course, it only make sense a single project for
component.



Regards
--
Ariel Constenla-Haile
La Plata, Argentina


"Aus der Kriegsschule des Lebens
        - Was mich nicht umbringt,
        macht mich härter."
        Nietzsche Götzendämmerung, Sprüche und Pfeile, 8.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Juergen Schmidt-3]

Hi Ariel,

i make it short, it's fine for me and i have only one point.

I would organize the repository

/api/examples/java/$TYPE/$EXAMPLE_NAME/source
/api/examples/java/$TYPE/$EXAMPLE_NAME/$IDE

But that is a minor concern only. I hope the decison which scm is used
tomorrow is ready soon that we can move forward with the new scm
directly from the beginning.

Juergen

Ariel Constenla-Haile wrote:

> Hello Juergen, Karl, *
>
> [instead of answering every individual mail, I collect here my opinions.]
>
> * all code should be on a respository, this is better for development. Sources
> can be tagged and for every OOo release zip files can be generated for the API
> end-user
>
> * Java sources and IDE's projects should be separeted on the respository; the
> projects should be only "skeletons", only containing project files; java
> sources should contain the sources and all common files (resources, config.
> files, etc.) This is the better way to maintain *only*  a set of sources and
> not one for every project type.
>
> * for the API end-user, the zipped projects should contain ready-to-user
> projects: no separated sources, no need to download anything else.
> This not only for the ease-of-use (relative sources may be confusing), but
> also becuase NB plugin (and Eclipse) does not support relative sources for UNO
> components.
>
> This means:
>
> * the packager zipping the projects will have to find a way to put all the
> separated sources inside the respective project
>
> * the developers working on the source code and the projects development, will
> have to find a way to design the projects so that they are configured as if the
> sources where inside the projects (otherwise the projects won't work for the
> end-user).
>
> In Linux I've found the solution for the later using symbolic links: NB treats
> the sources as if they where inside the project, cvs does not mess with the
> symlinks (don't know how portable this is to other plataforms...)
>
> For the packaging problem, I think the solution is in the repository design:
> with a structure like the following:
>
> /api/examples/java/sources/$TYPE/$EXAMPLE_NAME
> /api/examples/java/$IDE/$TYPE/$EXAMPLE_NAME
>
> for example
>
> /api/examples/java/sources/text/DevGuideTextDocumentExamples
> /api/examples/java/netbeans/text/DevGuideTextDocumentExamples
> /api/examples/java/eclipse/text/DevGuideTextDocumentExamples
>
> is very easy to write a script to copy everything from
> /api/examples/java/sources/$TYPE/$EXAMPLE_NAME to
> /api/examples/java/$IDE/$TYPE/$EXAMPLE_NAME
>
> and while copying, the script can rename according to the respective IDE
> requisites; for example, the extension manifest must be named
> "uno-extension-manifest.xml" for the NB plug-in, ...
>
> -------------------------------------------------------------------------------------
>
>
> Another point for better maintenance is separating what's common in every
> sources: for UNO components, the component loader/registration code; for
> client applications, the installation finder and class loader code.
>
> Something like the following could work:
>
> /examples/java/source/common
>
> with two folders
>
> clientapp
> unocomp
>
> mmm...well about the later I'm not so sure, because the component registration
> code is different in NB plugin and Eclipse plugin, so they could also be in
>
> /api/examples/java/$IDE/common/unocomp
>
>
> -------------------------------------------------------------------------------------
>
> Concerning the repository (and final zip) structure, I propose to group by
> application, where possible, and in the other cases follow the respective
> Dev's Guide chapter. For example:
>
> examples/java/source|$IDE/writer
> examples/java/source|$IDE/calc
> examples/java/source|$IDE/drawing
> examples/java/source|$IDE/database
> examples/java/source|$IDE/chart
> examples/java/source|$IDE/math
>
> not applications, but forming a closed group are
>
> examples/java/source|$IDE/forms
> examples/java/source|$IDE/ucb
> examples/java/source|$IDE/configuration
> examples/java/source|$IDE/gui
>
> the rest follow the Dev's Guide chapters
>
> examples/java/source|$IDE/FirstSteps
> examples/java/source|$IDE/ProfUno
> examples/java/source|$IDE/Components
> examples/java/source|$IDE/OfficeDev
> examples/java/source|$IDE/ScriptingFramework
>
>
> -----------------------------------------------------------------------------------
>
> Concerning how many projects we should make out of the examples, IMHO one
> project for client appl. with a class with main method is a non-sense.
>
> So I'd vote for grouping, where possible, the client appications in only one
> project/JAR.
>
> For example, all client apps. in
> /opt/openoffice.org/basis3.1/sdk/examples/DevelopersGuide/Spreadsheet
>
> grouped in
> examples/java/source|$IDE/calc/DevGuideSpreadsheetExamples
>
> all client apps. in /opt/openoffice.org/basis3.1/sdk/examples/java/Spreadsheet
>
> grouped in
> examples/java/source|$IDE/calc/SDKJavaSpreadsheetExamples
>
>
> In the future, new examples could be grouped in new projects, or in its own
> project, but for the existing examples this way makes clear where the example
> comes from (from the Dev's Guide, or from sdk/examples/java)
>
> For UNO components, of course, it only make sense a single project for
> component.
>
>
>
> Regards

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Karl Weber]

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.

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?
- Should it include the loader mechanism?
- If yes:
- - Will teh Loader remain part of the sdk?
- - Will the Loader always be found in
    <sdk-install-dir>/openoffice.org/basis3.1/sdk/classes/?

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






---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Steffen Grund]

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: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Karl Weber]

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
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.

OpenOffice.org is started by the Bootstrap class, which is independent of the
Loader... Or am I wrong here?

>
> > 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.)

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....

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...

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.

> 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.

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'?

-Karl

 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Juergen Schmidt-3]

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: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Karl Weber]

Hi Juergen,

Am Montag, 15. Juni 2009 07:21 schrieb Juergen Schmidt:

> > 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.

O.k., so I will continue the way I started, i.e. include the Loader.

Thanks for your answer.

-Karl.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...