Re: Info: potential SDK changes for OO.org 3.2

> Hello Juergen, Karl, *
>
> [instead of answering every individual mail, I collect here my opinions.]
>
> * all code should be on a respository, this is better for development. Sources
> can be tagged and for every OOo release zip files can be generated for the API
> end-user
>
> * Java sources and IDE's projects should be separeted on the respository; the
> projects should be only "skeletons", only containing project files; java
> sources should contain the sources and all common files (resources, config.
> files, etc.) This is the better way to maintain *only*  a set of sources and
> not one for every project type.
>
> * for the API end-user, the zipped projects should contain ready-to-user
> projects: no separated sources, no need to download anything else.
> This not only for the ease-of-use (relative sources may be confusing), but
> also becuase NB plugin (and Eclipse) does not support relative sources for UNO
> components.
>
> This means:
>
> * the packager zipping the projects will have to find a way to put all the
> separated sources inside the respective project
>
> * the developers working on the source code and the projects development, will
> have to find a way to design the projects so that they are configured as if the
> sources where inside the projects (otherwise the projects won't work for the
> end-user).
>
> In Linux I've found the solution for the later using symbolic links: NB treats
> the sources as if they where inside the project, cvs does not mess with the
> symlinks (don't know how portable this is to other plataforms...)
>
> For the packaging problem, I think the solution is in the repository design:
> with a structure like the following:
>
> /api/examples/java/sources/$TYPE/$EXAMPLE_NAME
> /api/examples/java/$IDE/$TYPE/$EXAMPLE_NAME
>
> for example
>
> /api/examples/java/sources/text/DevGuideTextDocumentExamples
> /api/examples/java/netbeans/text/DevGuideTextDocumentExamples
> /api/examples/java/eclipse/text/DevGuideTextDocumentExamples
>
> is very easy to write a script to copy everything from
> /api/examples/java/sources/$TYPE/$EXAMPLE_NAME to
> /api/examples/java/$IDE/$TYPE/$EXAMPLE_NAME
>
> and while copying, the script can rename according to the respective IDE
> requisites; for example, the extension manifest must be named
> "uno-extension-manifest.xml" for the NB plug-in, ...
>
> -------------------------------------------------------------------------------------
>
>
> Another point for better maintenance is separating what's common in every
> sources: for UNO components, the component loader/registration code; for
> client applications, the installation finder and class loader code.
>
> Something like the following could work:
>
> /examples/java/source/common
>
> with two folders
>
> clientapp
> unocomp
>
> mmm...well about the later I'm not so sure, because the component registration
> code is different in NB plugin and Eclipse plugin, so they could also be in
>
> /api/examples/java/$IDE/common/unocomp
>
>
> -------------------------------------------------------------------------------------
>
> Concerning the repository (and final zip) structure, I propose to group by
> application, where possible, and in the other cases follow the respective
> Dev's Guide chapter. For example:
>
> examples/java/source|$IDE/writer
> examples/java/source|$IDE/calc
> examples/java/source|$IDE/drawing
> examples/java/source|$IDE/database
> examples/java/source|$IDE/chart
> examples/java/source|$IDE/math
>
> not applications, but forming a closed group are
>
> examples/java/source|$IDE/forms
> examples/java/source|$IDE/ucb
> examples/java/source|$IDE/configuration
> examples/java/source|$IDE/gui
>
> the rest follow the Dev's Guide chapters
>
> examples/java/source|$IDE/FirstSteps
> examples/java/source|$IDE/ProfUno
> examples/java/source|$IDE/Components
> examples/java/source|$IDE/OfficeDev
> examples/java/source|$IDE/ScriptingFramework
>
>
> -----------------------------------------------------------------------------------
>
> Concerning how many projects we should make out of the examples, IMHO one
> project for client appl. with a class with main method is a non-sense.
>
> So I'd vote for grouping, where possible, the client appications in only one
> project/JAR.
>
> For example, all client apps. in
> /opt/openoffice.org/basis3.1/sdk/examples/DevelopersGuide/Spreadsheet
>
> grouped in
> examples/java/source|$IDE/calc/DevGuideSpreadsheetExamples
>
> all client apps. in /opt/openoffice.org/basis3.1/sdk/examples/java/Spreadsheet
>
> grouped in
> examples/java/source|$IDE/calc/SDKJavaSpreadsheetExamples
>
>
> In the future, new examples could be grouped in new projects, or in its own
> project, but for the existing examples this way makes clear where the example
> comes from (from the Dev's Guide, or from sdk/examples/java)
>
> For UNO components, of course, it only make sense a single project for
> component.
>
>
>
> Regards