2009 January | JPz'log

30Jan/090

Podcasted

Glassfish

I have been podcasted by Alexis on teaching JavaEE with Glassfish.

We discussed various things, including IzPack and Glassfish, teaching JavaEE with Glassfish, IDEs, web frameworks, and even what I would be up to next year (BTW I am looking for job, so do not hesitate to contact me).

Thanks again Alexis for recording this podcast!

Filed under: English, IzPack, Java No Comments

29Jan/090

Making a stable release from a Subversion trunk… with Git

I must confess that the first time I tried Git I truly hated it. Really.

Now things have changed: Git has improved a lot in terms of usability and I have learned how to use it properly. I recently found a very nice use case for its "cherry-pick" command.

IzPack officially uses Subversion. Since Git provides bidirectional inter-operability with Subversion, I happen to use it a lot this way to get the best of both worlds.

A common practice in Subversion is to have the "trunk" as the "always in development" branch, and have separate branches for stable releases. This allows having maintenance releases while preparing future releases in the trunk. All you have to do is commit bug fixes to your "stable" branches and merge them back to the trunk. However for some reason we (IzPack developers) did not respect this policy, which led me to the conclusion that we would not be able to make a 4.2.1 release since everything (i.e., not just fixes!) went to the trunk.

Fortunately I had this idea to leverage Git and its non-linear history model to rebuild a stable branch on top of 4.2.0, so that we could prepare a 4.2.1 release (and even 4.2.2, who knows?) while 4.3.0 matures.

The big picture looks like this:

I maintain a public Git repository for IzPack on Github that I regularily synchronize with Subversion.

Once I got the Git commit that matched IzPack 4.2.0, I just had to create a branch using that commit number, which is something like:

git checkout -b 4.2 (hexa code)

The remaining of the process is fairly simple. I use the excellent GitX tool to browse the commits from the branch that matches the Subversion trunk (note that gitk is fine as well). I also have a browser next to me to review the JIRA issues and know if a given commit is a new feature, an enhancement or a bug fix.

When a commit matches a bug fix, I quote the commit number, and cherry-pick it:

git cherry-pick (hexa code)

In my case, the resulting "stable branch" that I have obtained has been pushed to Github.

Finally I would like to mention that... of course you can do that with Subversion, but in a much less friendly manner: do merges from your trunk back to your branch by picking the commits revision ranges. That's possible, but definitely exhausting (who said I loved trolls? )

Filed under: English, Geeking, Howto No Comments

25Jan/091

Feeling proud

I can't help but feel really proud sometimes when I download a software...

By the way if you have some tips on using jBPM and Drools on Glassfish, do not hesitate to comment.

Filed under: English, IzPack 1 Comment

19Jan/090

Code coverage reports made easy

Test-driven development is a wonderful thing that really boosts your productivity... unless of course you fall into some kind of extreme dogma (ok, you should avoid static methods, but claiming that they can't be tested properly is a fallacy).

Actually this post is not meant to advocate TDD.
Others do it way better than I anyway, and this is a topic that has been reharshed, and reharshed, and... reharshed right?

So starting from here I assume that you are using TDD in your projects with care and intelligence. And if you're not, try TDD for real to understand their benefits and drawbacks.

Keeping the bar gteen is fine, but we often forget to properly track code coverage. Indeed, there is no real point in keeping the bar green if your tests cover 10% of the code that you have actually written!

Lots of tools exist to fill this need. One that caught my eye recently is Cobertura. It's a very good one, distributed under the GPL (and since you are probably not modifying it at all, the license should not be an issue).

Cobertura tracks down code coverage metrics: line coverage, branch coverage and complexity. It generates Javadoc-style HTML reports, and for each class, you get the source code highlighted with useful informations:

the number of times each line / branch was accessed
lines and branches that have not been accessed appear in red

Cobertura is easy to plug into Maven:

You can then run:

mvn cobertura:cobertura

and get the reports in target/site/cobertura

Easy isn't it?

Cobertura can vastly improve your tests suites if you run it from time to time to spot the areas that have not be caught by your test cases.

Of course don't try to target 100% of code coverage (that's stupid and silly, really): there are always some parts of your code that don't need testing. An easy example is a trivial getter of setter.

Filed under: English, Geeking, Howto, Java No Comments

Older Entries »