Archive for June, 2009

Throughout my career as a developer, one “mantra” that has been deeply ingrained into my brain is “commit away, but DON’T BREAK THE BUILD!”. Breaking the build can include things like breaking checkstyle/pmd checks, committing code that doesn’t even compile, having unit/system test failures, sticking dependencies in the poms that don’t exist in declared repos (example: depending on a SNAPSHOT you built locally) , etc… Bunches of things.

Breaking a build on something you’re the only one working on is usually not a huge issue. Just commit a fix at some point and no-one will ever know. However, when working with a large team or working on OpenSource where people all over the world could be building it, break a build can be a serious issue. If the build is broken, you can easily have MANY engineers wasting a lot of time trying to debug something they shouldn’t be. That can be quite “expensive”.

For example, if I run the tests and see a test failure, I assume one of my changes is the cause of that. Thus, I start debugging and try and figure out what I did. I shouldn’t be trying to debug into tests that aren’t caused by my changes. The code base should be stable and just work.

Unfortunately and apparently, there are a lot of people that don’t believe the same as I do. The Hudson Continuous Integration Game plugin provides an interesting way to see who believes what. Basically, for each build done in Hudson, the plugin assigns a score. If the build succeeds cleanly, all developers that contributed changes get a point. If the build fails spectacularly (fails to even compile), it’s -10 points. A failing unit test is a minus point. Fixing a failing test is a plus point. etc… Thus, over time, people that tend to break things end up with less points (even negative) and those that tend to fix things and/or commit clean code end up positive. Obviously, it’s not perfect. People that commit a LOT can earn higher scores as they can get one point per commit. I commit a couple times a day. Thus, I have potential to get more points than someone who only commits a couple times a week.

Looking at the Apache Hudson Instance Leader Board, you can see quite a range of scores. IMO, there are entirely too many people with negative scores. Something for those people to start working on. Get to work! :-)

This past week, the Apache CXF team released the latest patch for the 2.2.x series: 2.2.2. Normally, patch releases aren’t very exciting. Usually just a bunch of bug fixes. However, this release provides two extremely noteworthy bullets:

  • JAX-RS 1.0 – 2.2.2 is the first release of Apache CXF to pass the JAX-RS 1.0 TCK. The 2.1.x versions of Apache CXF introduced some preliminary versions of JAX-RS based around the 0.6 and 0.8 versions of JAX-RS. 2.2.0 updated the basica API’s to 1.0 level, but was not fully JAX-RS 1.0 compliant. We finally got access to the TCK a short while ago and 2.2.2 includes all the patches and fixes necessary to get CXF to pass the 1.0 TCK. We still have a bunch of ideas and plans to make the REST/JAX-RS support in CXF even better, but passing the TCK is an exciting milestone.
  • JBoss-WS – the JBoss WebServices team released JBossWS-CXF 3.1.2 based on Apache CXF 2.2.2. This release of JBossWS-CXF is the first to completely pass the various JAX-WS/JWS/SAAJ/JAXR parts of the J2EE CTS/TCK. This is just the first results of the JBoss/CXF collaboration. To achieve this, JBoss did identify and submit patches for several issues in CXF. They also done extensive testing with their own stack, .NET, and others to make sure CXF will completely meet their needs. JBossWS-CXF 3.1.2 is a result of all of that, but it’s also just a beginning. Now that the TCK is passing, we hope to expand the collaboration into more than just “tck bug fixes” with new features, new ideas, etc…

Anyway, definitely another exciting week for Apache CXF. Many thanks go out to the entire Apache CXF team, the JBoss folks that identified and fixed issues, and the Progress FUSE team for helping with the testing and development.