Guidelines for XmlBlaster core developers
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. Coding/documentation should be in English. |
Follow the common look and feel of xmlBlaster. 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 code. 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. |
Here you see how the requirements are presented online.
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 feature in there.
It takes you one minute but allows us to track exactly the state of xmlBlaster.
With XSL style sheets we will generate
|