Login | Register
My pages Projects Community openCollabNet

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: 2008-07-01 02:29:13 -0700 (Tue, 01 Jul 2008) $.