Am Donnerstag, 26. März 2009 11:16 schrieb Juergen Schmidt: > Karl Weber wrote: > > Hi, > > [...] > > 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.
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? 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.) 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. 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. > > > 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 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? How do you enforce that every project uses identical source code? 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? > 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 ... 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...? > > > (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? -Karl --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
