Unit Test and Constructor IoC

28 10 2008

I might have said it before but, Constructor IoC has 2 big advantages over setter and getters.

  1. The IoC all happens in one shot, so there are no issues about a class being half configured, its always thread safe from the start.
  2. When doing writing Unit tests is really clear what is needed to make a class function
  3. Less code.

That was 3… oops… bloat 🙂

Advertisements




Increasing Code Coverage

25 10 2008

One of the problems for developers, is that the honest ones want to increase their code coverage and unit tests, but dont really know how much of their code isnt tested. There are solutions to this. You can add a coverage report to maven and build a site, or you can use an eclipse plugin, which is more interactive. http://www.eclemma.org/ works well inside eclipse and gives good information about the lines being covered. The temptation with this evidence that code is covered or not, is to chase the % coverage up, by devising unreal ways of exercising the code. This should be resisted at all costs, as it will give a false sense of security, but it would be get to the point where the last 5% of coverage is all there is to worry about.





Performin a Mvn Release (Notes)

15 10 2008

Maven perorms a release by editing the pom files and replacing the version numbers, it then commits the edited files after a build. Having doen that it re-edits the poms to the new trunk, and commits again.

The standard release plugin configuration does a mvn clean verify, which can fail if you have plugins that depend on artifacts that should have been added to the local repo. You can change this by either doing a mvn clean install after the failed mvn release:prepare, or re-configure the goals for the release plugin. (see below).

mvn release:perform only checks out the tag, and runs the perform goals usually deploy site-deploy, so you can do this step manually with a checkout and a mvn deploy.

The other thing that the mvn release:prepare does is edit all the svn urls to match the new destination of the tag, so when doing a branch its probably best to use mvn release:branch -DbranchName=kernel-1.0.x to perform the branch as this will keep all the svn urls in place.

The final thing on the release, where no SVN urls are specified in the pom, the fielsystem path from the last pom that did have the svn urls specified, MUST match the the path in SVN otherwise the tagging/branching/committing will get lost and muck it all up. I find it easier just to spevify the location in svn in each pom.

So, here is how to re-config the goals used to verify a tag, I have added install because I have an assembly project in the build that needs things in the local repo.

<build>
<plugins>
...
     <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-release-plugin</artifactId>
        <configuration>
        <preparationGoals>clean install verify</preparationGoals>
        </configuration>
      </plugin>
</plugins>
</build>




OSGi version resolution

5 10 2008

OSGi version resolution looks great, but there is a problem that I am encountering. I can deploy more than one version of a jar as seperate OSGi bundles, but unless the consuming bundle was explicity written to specify a range of versions that bundle will not start.

Bundle A was built with a dependency on package org.apache.commons.useful;version=1.0.2, which means any version > 1.0.2.

I deploy bundle B with org.apache.commons.useful version 1.0.4, great no problem.

Bundle C depends on org.apache.commons.usefull;version=1.0.8,

So I deploy bundle D with 1.0.8, great for Bundle C, but now Bundle A can see 1.0.4 and 1.0.8 and wont start, due to a constraint violation.(at least in Felix).

To make this work I have to go back to bundle A, and rebuild it with version=”[1.0.2,1.0.8)” meaning “I depend on any version >= 1.0.2 and < 1.0.8|. Thats all fine, but, now every time I add a second version of a jar to OSGi, I have to go back and repackage all the bundles that dont have precise enough version numbers.

You might argue 1.0.4 and 1.0.8 are equivalent so dont deploy bundle B anymore, but the same problem happens when you try and deploy bundles container 2.0.6 and 2.5.5 when 2.5.5 is not fully backwards compatable.

Worse, this also means if I took any 3rd party bundles without precise version ranges, I will have to work out how to rebuild them. Not exactly and inviting task when you have > 100 bundles in a container. Makes me wonder if its worth all the hassle.