Cobertura is gone and Clover is here

I have spent most of this week working on integrating Clover into our environment and ripping out Cobertura. I ran into a couple of issues along the way, but we are up and running now. First one thing I dislike about Clover is by default they will mess with the maven artifacts that you may intend to ship. I think this is actually a poor way to instruct people to configure it out of the box because you are basically saying you only run it every so often on different builds or you end up having to invoke maven multiple times or other associated hacks. I didn’t like any of those options as the idea is to fail the build if coverage drops below the acceptable level and not accept the commit until that is addressed. Luckily I stumbled upon the clover2:instrument option that you can use instead of the default recommended clover2:setup goal. But then I hit a second problem, the way it names the instrumented classes with the clover2:instrument option seemed to be clashing with the JPA 2.0 Metamodel generator that we were using. I had sort of been looking for an excuse to rip that whole thing out of the project for a while and now I finally had that so I removed it from our software and replaced it with just reflection on the classes and used unit tests to verify at test time that the code wasn’t broken instead of the compile time checks we would get with the metamodel. With that gone clover integrated greatly and I got it wired into our Jenkins configuration. Today I was able to get our configuration manager to install the clover plugin into Jenkins instead of using the publish html report option and we have much nicer integration. With the Sonar Clover plugin we now have integration with Sonarqube. The Sonar plugin brings in the coverage but it no longer lists technical debt like the Cobertura does. So aside from that I think this is going to be a much better solution for us going forward and was glad we could finally switch.

Project Estimation

The thing I dislike most in software development is when they ask me to estimate how long a given project will take. I am about to start a new project so of course the first thing that is asked for is to do some research and try to figure out what the high level tasks of the project will be and estimate how long they will take. This seems like a reasonable thing to do as obviously if the company is going to invest a lot of money into a project they want to have sort of a guess how much the project is going to cost. Additionally if the scope of the work is outside the time frame in which they need the feature they can decide whether or not to limit the scope of the project or add resources to the project. So all in all I can see the need and the point of it, but I think I dislike it cause I am not very good at it.

The first project I led at my current company I came up with a bunch of estimates and actually did a pretty good job of identifying the major areas of work that needed to be done. I went through and applied my time estimates and based on the features I felt I understood very well I delivered fairly tight estimates and the features I had less understanding of I added extra padding for research and learning time. Then I got into the project, and the parts I thought I had the biggest handle on was actually much bigger than I had realized. I had I think 2 weeks of work on one aspect that actually ran like 6 weeks. I believe the whole project was a 3 month project. So of course the project manager was sweating it a little bit. I told him don’t worry I always hit my dates and if I think the date is in danger I will let you know immediately. As we went on the other aspects that I didn’t feel like I understood as well turned out to be easier than expected and I made up the time there. By the end of the project I delivered on the exact date I had promised 3 months previously and I didn’t put myself into a death march so I considered that a successful project. From an estimation point though maybe it was a failure as all my estimates were off even though I delivered what they wanted when they wanted it.

So here I am again working on an estimate for a new project wherein the date is already known. I guess at this point my thinking is make sure I have a decent enough understanding of the project so that I have the resources to hit the date, and hopefully the experience of that first project will help me to not be too aggressive on the parts that I think I understand as there are probably some icebergs and also not too lax so that at the end I deliver on the date we need it or a week or 2 early and have enough resources to do so that I am not in a death march. Wish me luck.

On a positive note I resolved all the issues with our new SonarQube server instance and we transitioned to it last Friday. We are now able to use the plugin in IntelliJ to download the data and analyze our local projects which is a big step forward. Additionally running it as one unified Sonar job from the parent pom instead of invoking it on each maven module has resulted in a speedup by 10 minutes on our builds with Sonar analysis and better Sonar coverage overall (Previously some taglib libraries and a few other small things weren’t being analyzed).

Getting crushed by SonarQube

I have been upgrading our Sonar server from 4.5 to 4.5.2 and restructuring our project. I initially was planning on upgrading to SonarQube 5.0, but the upgrade process can’t seem to handle our database. After I upgraded to 4.5.2, I was restructuring. Initially we had each of our libraries setup as a separate project at work and there was a separate sonar project for each one. At one point we decided it was much better to consolidate them all under 1 git repository and make 1 maven master pom with each other project as a module in maven. When we did that we never got around to consolidating our Sonar project to 1 project with sub projects. After we upgraded to intelliJ we found that we couldn’t sue the sonar plugins to integrate with our environment as our project didn’t match our sonar project.

Hence I started working on restructuring it to reflect our current project structure. Of course me being me the first thing I want to do is update to the latest. After the Database Schema Upgrade to version 5.0 failed I restored from a previous backup and then did the upgrade to 4.5.2. After upgrading I also had to upgrade many of our plugins. Upon completion of that I ran the analysis and started working on fixing the new errors. I was getting pretty close to having all the issues fixed when I discovered many of the rules we were using were deprecated. We had 99 deprecated rules plugins so I disabled them and enabled the suggested replacements. Oh what a mistake, after being down to about 60 issues to fix that put me up to 1000. Ay!!! At the end we will have much better rules in place for our code, but after working on it all day today and not quite resolving all the issues I am sort of kicking myself for upgrading too much at once. Oh well I guess in the end it will be worth the pain.