Hi Ariel,
i make it short, it's fine for me and i have only one point.
I would organize the repository
/api/examples/java/$TYPE/$EXAMPLE_NAME/source
/api/examples/java/$TYPE/$EXAMPLE_NAME/$IDE
But that is a minor concern only. I hope the decison which scm is used
tomorrow is ready soon that we can move forward with the new scm
directly from the beginning.
Juergen
Ariel Constenla-Haile wrote:
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
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
