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
d...@documentation, continued at dev and finally continued at d...@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: [email protected]
For additional commands, e-mail: [email protected]
