XRadar Development Process

Tasks, bugs and change requests

Whenever you do a change in the XRadar, make sure you are working on a change that is defined as a issue in the sourceforge project page. The 3 change types and one patch type that are used on the XRadar are as follows (corresponding links to sf-page):

  • Tasks are the primary means for changes planned by the XRadar project team. They are categorized and prioritized when commited.
  • Feature Requests are features that the XRadar user community wants. Simple feature requests are commited as they are. Complicated feature requests, are prioritized and get one or more Tasks associated with them.
  • Bugs are bugs that the XRadar user community or developers have detected. These are fixed as they are. No tasks are necessary.
  • Patches are fixes to bugs on older releases. These fixes can come from the user community or the XRadar developer. These are closed when the bug-fix is incorporated into a new XRadar release.

Guidelines when developing

The recommended way to insert a new change to the XRadar is :

  1. Assuring that the testproject is set up with sufficient information to simulate what you want. If not, extend one or more of the releases in the testproject. Assure yourself that the testproject also can simulate the necessary negative tests.
  2. Implement the chage iteritavly on statics and/or dynamics until satisfied with change.
  3. Always look for refactoring possibilities in your work in order to simplify, increase comprehension or remove duplications. Even though the XRadar was build to monitor quality, it needs a lot of cleaning up itself. Be sure test extra in refactoring circumstances.
  4. Commit change.

In ant, there are several targets you can use to shorten the development feedback cycle. Below, a few of the most important are mentioned:

Target(s) Property Use When
statics_current You have done changes that affect both processing and reporting in one statics version.
statics_current -Dgenerate.report.only=true You have only changed the radar-config.xml, report-templates or graph-templates.
statics_current -Dskip.analysis=true You changed merging-scripts, but no new classes or basic analysis is needed.
statics_current -Dinclude.junit=true -Dinclude.cobertura=true You are working on test metrics.
dynamics_current You have only done changes to the dynamics reports or graphs.
dynamics_all You have done changes to the dynamics processing structure, or multiple statics version have been changed.

When you are used to the XRadar structure, making changes goes fast - so have fun!

Checklist when checking in source

There is no CI-server running the XRadar build, but several users check the XRadar out directly from SVN. That means that the quality requirement of commited changes are very high. That does not necessarily mean that you cannot commit a halfdone change on a totally new report, as long as you are sure that existing funcionality has not been broken. Hence, we need a short checklist:

  • Have done a "SVN update" before your commit?
  • Have you run : ant statics_all dynamics_all and lookeed over the relevant reports before the commit?
  • Have you added all new files to SVN?
  • If relevant have you documented the changes in the maven-project and run maven site:generate?
  • Have you mapped the concrete change to an issue in the cvs-commit comment?
  • Have you updated the status of the issue you have been developing on?