ArgoUML Subprojects
During 2005 the ArgoUML project at Tigris was re-organized
in a set of Tigris subprojects.
The purpose of this is:
- To better promote these projects as focus areas.
- To get a better separation of the source and responsibilities
in components.
- To make it easier to recruit new developers.
- To get separate commit mailing lists so that developers to a greater
extent can select what they find interesting to monitor.
- To make better use of the Tigris authorization mechanisms.
The experimenting with setting up project-specific roles and
allowing these roles to edit parts of the repository
lead to the conclusion that this involved a lot of
tedious and error-prone work and some hard to investigate problems.
The current plan for how this will work is:
- All subprojects will have the same file organization (src, build.xml, ...)
This will eventually be described in
the
Cookbook (Chapter 2).
- The same tools will be used for all subprojects (ant, checkstyle, ...).
- All subproject will have names and mailing list prefixes that follow
the same policy
(names argouml-whatever and
mailing list prefixes argouml-whatever-listname).
- Releases will be built from several subprojects.
This has several consequences for
subprojects that are included in the releases:
- All subprojects have the same release plan.
It is the from Release Plan
from the ArgoUML project.
- All subprojects have the same release numbering.
- Developers of subprojects are requested to monitor
the dev@argouml.tigris.org mailing list
to get information and discuss planned releases.
- The subprojects will obey the exact same rules w.r.t.
compiler version,
other tools needed to build.
- The tagging and branching rules from the ArgoUML main project apply.
- The subprojects will use subversion as the version control system.
- The nightly build and other static checks will work over several
projects, i.e. all projects included in the releases.
- Java Web Start starts will be made to include subproject result.
- Subprojects will not use their own issuezilla.
Instead bug reports will be filed in the ArgoUML issuezilla where
subprojects will get their own subcomponent.
The reasons for this are
to reduce the work for the release manager when he is to maintain
the versions and target milestones,
to make it easier for our users to file bug reports, and
to make it possible to move a miss-filed issue from one subproject
to another (or back and forth between the main project).
This requires that persons developing in a subproject
to hold an Observer role in the main project to be able to work
with the issues.
- The same licence and code conventions apply to all subprojects.
Other ideas that we have collected sofar in this work and that we will
have to work more with:
- Organizing one subproject for each natural language,
makes it possible to create
an ArgoUML community in that language,
complete with translated web site, mailing lists in that language, ...
See the Norwegian Bokmål
project.
- When developing modules that add functions to ArgoUML,
it would be nice if you don't need to check out and build the complete
ArgoUML project from source.
I (Linus Tolke) think this is possible but it needs to be documented
and perhaps improved upon.
- The build.xml of all subprojects should follow the same rules i.e.
the targets should be defined as to what they do.
Linus Tolke plan to develop this by documenting this in the Cookbook.
Last modified $Date$.