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: [email protected]
For additional commands, e-mail: [email protected]
