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.
Good news this week. Our purchase of Clover was approved and we will have our license keys in a matter of days. As of tomorrow it is going into our build and Cobertura is getting ripped out. You may recall I previously wrote about my issues with Cobertura. One problem was the latest version at the time 2.0.3 didn’t work with Powermock, even though 188.8.131.52 did. And the second issue I was having with it was the lack of Java 8 support since we are close to upgrading on our project at work. Well oddly enough early in this week I saw Cobertura had a new maven plug and a new release 2.1.1. I immediately updated to the 2.7 plugin to give it a go and it promptly failed on Powermock like 2.0.3. So I didn’t feel bad at all when 2 days later I found out our Clover purchase request had been approved.
The other thing I have been messing around with in my spare time is Wikitree. Wikitree is basically a Wiki meets Ancestry. Full disclosure I am currently an Ancestry.com subscriber. What I like about Wikitree vs Ancestry is that in theory it is 1 tree that everyone is working on. Instead of everyone having their own trees and you sort of connecting to other people researching common ancestors and pulling some of their data the goal of this project is just one tree and you link in when you meet up at common ancestors. This seems like a better model for collaboration assuming that the people with your common ancestors are open to working with you on their pages. They also seem to do privacy well which Ancestry does in that if people are alive there is a much more limited set of information that is released and the farther back you go the more information that is public. Now I have one HUGE complaint with wikitree. They don’t support SSL. Not for the entire site, nor even just the authentication page. This is pretty ridiculous in 2015. If they had it on the authentication page at least your password wouldn’t be flying in plain text, but your session could still be hijacked. At this point I think it reflects pretty poorly on any organization if they don’t support basic web security. Worse on a site like this where they purport to protect the privacy of people working on it, without actually taking the most basic of steps to do so.
Me being me I figured I would email Chris Whitten the founder of the site. And to his credit he immediately got back to me, however his response was less than satisfactory. He stated the following:
We worked on implementing SSL site-wide and it was much more difficult
than expected. We could protect just your login password, if that’s
To me this sort of is someone who fundamentally doesn’t really get it. While protecting the privacy of my login password is a good start at this point given the sensitivity of some of the information (Birth dates, Mother’s maiden names, etc), I would expect that security is a higher priority at the site, but apparently that isn’t the case. Hopefully they make it more of a priority as I would like to make it my main family tree site and migrate away from Ancestry, but if they don’t care about their members security I am not sure if I will be able to do so.
In my current position one of the metrics we track is code coverage for our unit tests. When I started at the company we were using JUnit with Mockito and JaCoCo. This was a pretty good setup we got good coverage reports and Mockito makes the testing writing much easier.
One of the limitations of Mockito is that you can’t mock private methods or static methods. This presented an issue for us in reaching our desired level of coverage. We initially worked around some of the private method issues using reflection, but it wasn’t always ideal. The decision was made to use PowerMock. PowerMock solved all of our Mockito issues immediately. It was compatible with Mockito but gave us some new powerful features to allow us to get much better unit test coverage. Then we ran our Jacoco reports and found that the reporting no longer worked. Due to the way PowerMock uses byte code manipulation in order to mock static methods it is not compatible with JaCoCo and there is no plan for them to support measuring that.
So we figured no big deal and switched to Cobertura. The first problem with this change is that Cobertura 2.0.3 has a regression in it so it won’t report coverage with Powermock. We figured no big deal we will run the 184.108.40.206 release of it until they release a bug fix so we can update. Unfortunately the update has never come. You go to the roadmap for the site and you see it hasn’t been updated since November 7, 2013. There appears to be very little activity on the project, and we haven’t seen an update in 2 years. I see work going on in the github repository but there seems to be no attempt and doing any maintenance or fixing the issues for the existing users, and I can’t get a feel for when the 2.1 release is ever going to come out. A second issue is that the current version doesn’t support Java 8 and I would like to update to Java 8 in the very near future. At what point when dealing with open source software do you say the project is either dead or too inactive for us to rely on for business needs?
Cut to last week I was updating some libraries in the project and I wanted to upgrade from PowerMock 1.5.5 to PowerMock 1.6.1 and my coverage reports went to 0. So it seems our old version of Cobertura can’t handle the latest PowerMock. I did a test with Atlassian Clover and our coverage reports worked perfect and looked better than anything I have ever seen for a report. At that point I decided I had reached my breaking point with Cobertura and put in a request that we move to clover and buy some server licenses and work and in the meantime while waiting for approval I had to settle for PowerMock 1.5.6 until we can get approval to buy Clover licenses.
Going forward when someone suggests a new tool to fix an issue that we are having, I have to say that I am going to be looking into other things that tool drags along with it as I don’t want to be in the situation again where we are trading one problem for another.