This post originated from an RSS feed registered with Java Buzz
by Florian and Rolf.
Original Post: Make your tools playing together nicely
Feed Title: Heulen wie ein Schlosshund
Feed URL: http://www.contegix.com/blog/index.rdf
Feed Description: Florian and Rolf talk about the trials and tribulations of software development in the java world.
I'm a big fan of incorporating static source code analysers into the the system build. It is a comfort to have an automated code-cop ensuring that standards don't slip. I've experienced the beneficial effect tools such as Checkstyle and Simian have had in ensuring that cruftiness does not creep into the code base on many projects. I've also had the bad experience of joining projects whose code base did not have these guide wires in place and they have usually (with minor exceptions) contained the sloppiest code.
A standard practice is for these static source code analysers to be included as part of the continuous integration build, even having these tools fail the build if certain violations are encountered.
e.g.
fail the build if there is code with a ten line block 'copy and pasted' between classes
fail the build if a method has an n-path complexity of over 100 etc.
This practice works best if the developer's private workspace build mirrors (as much as possible) the continuous integration build. In fact this should be a goal for any development system; reduce the number of continuous integration build failures by ensuring the developer's private workspace build is run before code check-in and try to make this pre-checkin build incorporate as many of the features of the continuous integration build as time constraints will allow.
Obviously a full continuous integration build could take some time and we really do need to make the private workspace build complete as quickly as possible. We don't want developers to be dissuaded from checking code into the repository just to avoid the overhead of running a build. Emphahsis should be placed on including the fail-fast components of the continuous integration build. That includes, obviously, the compilation step and the unit-test step but should also include the static code analysis step.
When choosing the toolset for your project, the needs of the private workspace and continuous integration builds should be considered. Make sure that the chosen tools can be run as part of these builds. If you (sensibly) choose to incorporate static code analysis into your project then make sure it can be incorporated into the build and used to fail the build.
Try to avoid combinations that don't work. Avoid choosing build tools that don't have easy plugins for the tools you wish to incorporate into the build. For example, the Agitar extensions to checkstyle don't have a plugin for Maven. Agitar has extended checkstyle with new checks but, as far as I can see, these new rules have not made it back into the Checkstyle project. That means that, if you choose to use these new checks and you have also chosen to use Maven to build, you will need to code your own agitar checkstyle plugin. This doesn't appear to be a simple task once you realise that the agitar product has dependencies on things with names like agitar-commons-collections.jar and agitar-gnu-regexp.jar. It soon becomes obvious that the agitar guys do like to personalise open-source projects. Customising the existing checkstyle plugin is not as straight forward as changing the references to point to the Agitar flavoured libraries.
A lot of IBM shops seem to structure projects into many subprojects (as do Maven shops). e.g. one project for the Web artifact, one for the EJB artifact, one for the EJB-tier classes etc. If you take this approach then make sure that you are capable of writing a new plugin to enable Simian to analyse for inter-project copy-and-paste. The current Maven Simian plugin does not seem to provision for inter-project checks; each project is seen as a separate entity.
I can understand how these decisions can happen (and please, no smartarses say it's just down to Maven), especially when you are trying to choose your whole project toolset at the same time. Sometimes it is easier when circumstances dictate that the tools are introduced gradually; interoperablity becomes more obvious.
If you are about to startup a new project then think about the features you need then make sure the toolset that provides these features will play together well.