« 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 Karl Weber
::
Rate this Message:
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@...
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@...
« Return to Thread: Info: potential SDK changes for OO.org 3.2
| Free embeddable forum powered by Nabble | Forum Help |
