« Return to Thread: Info: potential SDK changes for OO.org 3.2
Re: Re: [dev] Info: potential SDK changes for OO.org 3.2
by Juergen Schmidt-3
::
Rate this Message:
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@...
> 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?
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.
>
> 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?
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...?
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?
>
> 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@...
« Return to Thread: Info: potential SDK changes for OO.org 3.2
| Free embeddable forum powered by Nabble | Forum Help |
