Last updated $Date: 2000/02/25 13:51:00 $ $Author: ruff $

Guidelines for XmlBlaster core developers


Getting started

Subscribe to the mailing list and discuss your ideas. And - very important - start hacking.

If you don't like the guidelines, discuss it on the mailing list, enhance them or change them if it makes sense and respects the other core developer feelings. But don't say this is rubbish, and do nothing.

Style Guide

Follow the common look and feel of xmlBlaster.
But follow this rule please:
We don't use any tabs for indenting, indenting is done with 3 blanks per level. We know, this discussion is as old as mankind. But we choose for xmlBlaster this way.

Testing

For every feature, a test case!

We have a test suite for xmlBlaster, you find it under xmlBlaster/testsuite/org/xmlBlaster.
Please! Add a test case there for everything you hack!

Because many people develop xmlBlaster, and you develop for the world, we need a full automatic test suite!!!

Like this, before committing changes, we type 'make test', and if the test suite shows 'green' we can sleep well.

Believe it or not, this is a MUCH more relaxed developing style. Imagine you make changes or enhancements in somebody else code. You dare much easier to do so, if you know the test suite reports if you broke some parts of the code you didn't understand or wasn't aware of.

Please minimize manual tests on the screen, nobody will run them. There is hopefully always a possibility to test your feature automatically with the test suite.

Requirements

In the directory xmlBlaster/doc/requirements there is one xml file for every xmlBlaster requirement.

Please! Take a copy of one of those, and note your hack in there! It takes you one minute!

With XSL style sheets (still missing :-), we will generate

  • A html table of supported features in xmlBlaster
  • A list of open topics, where developers can pick some and hack it
  • A printable reference manual from xmlBlaster
  • And one thousand things more
We are lazy, and this approach is simple and can be done with any vi editor.

The requirement should have a pointer to the testsuite, where this requirement is enforced.

HOME