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