sam://

Currency

2011-03-07T19:48:00.007+11:00

I'm in Europe, sometime I need to write prices in euro, in emails, documents etc. However I use an American keyboard, on a mac, which makes things a bit trickier when one wants to use the € symbol…

But I found a shortcut that works, I just have to remember it now:

⌥ + ⇧ shift + 2

Injecting enums with the Spring Framework

2010-07-22T23:47:00.004+10:00

Today I needed to inject an Enum into a bean's constructor using Spring.

First I thought I'd need to write my own FactoryBean or 'better' a PropertyEditor.

Well no need, it is already nicely handled by the framework. After a bit of googling, I found the documentation in Appendix A of Spring's reference

And here is what actually works just fine. If I have the following enum:

public enum Language {
 EN, FR
}

And the following class that I need to instantiate with Spring:

public class LocalisedLogger {
 private final Language lang;
 public LocalisedLogger(Language lang) {
   this.lang = lang;
 }
}

Then I can just configure it like this:

<beans>
 <bean id="logger" class="org.leberrigaud.example.LocalisedLogger">
   <constructor-arg value="FR">
 </constructor-arg>
</bean>
</beans>

That'it! Spring does the rest…

Java versions on Snow Leopard

2010-07-21T21:58:00.001+10:00

It seems I have a few issues with java and versionning theses days. This time I got bitten by Java's version on Snow Leopard. Indeed whatever version you think you're using it is Java 1.6!

What got me is the JDBC api and namely the new java.sql.Wrapper interface added in 1.6. Thank god for build boxes (running Linux ;-))

I now remember that I had to install manually Java 1.5 on my work machine, when I was in Sydney. I am now working on my laptop and forgot to do that. I couldn't remember the exact procedure but someone wrote it for me. Thanks to Ted Wise!

Java major.minor version

2010-07-20T21:29:00.004+10:00

You're bound to see those errors at some point if you're a java developer, something that says Unsupported major.minor version 49.0, or similar.

I always forget which number corresponds to which version of Java, so there it is:

JDK 1.4: 48.0
JDK 1.5: 49.0
JDK 1.6: 50.0

Initialising a git-svn repo from a given date

2010-07-12T17:52:00.003+10:00

The issue is that git-svn only lets you specify a revision number from which to init a repository. So first you have to find out the revision number at which your repository was at a given date.

You need to use SVN for that, and it's log command:

svn log -r {2009-12-31}:{2010-01-01} http://svn.example.com/repo/trunk

This command will log all svn commits which happened between the 31st of December 2009 and the following day, 1st of January 2010.

Then from the logs just pick the commit from which you want to init your git-svn repository and there you go:

git svn clone -s -r72569:HEAD http://svn.example.com/repo/

Here the chosen revision is r72569

Using Git with SVN repositories

2010-06-28T23:46:00.006+10:00

I've been using Git with SVN repositories for a while now. And for the most part it's good, really good.

If you want an introduction on where to start I suggest you read Emmanuel Bernard's entry on this exact topic. It's simple, to the point and will get you started in no time.

Today though I got bitten by some rather strange 'bug' of Git SVN. My master branch wasn't linked to remotes/trunk as I always expect. Apparently the branch that was last commited to (in SVN) is the one that gets linked to master.

Thankfully there is nothing that a quick Google search can't fix. And I found that one just has to issue the following command to fix that:

git reset --hard remotes/trunk

Thanks to Horst Gutmann for posting this before me.

Update:

A simple way to know what master is linked to is to issue the following command right after you cloned your SVN repository:

git svn dcommit

It will actually tell you where it is going to commit anything that should be.

Maven dependency heaven?

2010-01-26T10:00:00.000+11:00

If you search Google for "maven dependency hell" you'll find many answers. It can be summarised to two types of root causes.

Transitive dependencies

The most usual one is a fact of transitive dependencies. Transitive dependencies are great but with them comes dependency resolution. Which in turns means that changing one declared dependency in your project can affect any part of your dependency tree. Most of the time this happens without the developers noticing at least until an issue comes up. This can be triggered by something as simple as changing a dependency's version.

Remote repositories

The other cause comes from a combination of inconsistent (remote) repositories and different build environments. If your different build environements, developement, continuous integration, release, talk to different repositories then you might get a different dependency tree. As a simple example, at work we have a repository where we deploy sources of libraries that don't provide them otherwise. This is great. However if someone deploys the source with a minimal POM depending on your build environment you might get the wrong POM. And this means a different dependency tree.

Continuous dependency management

I believe Continuous dependency management is the solution to this problem. Each time you build you have to know precisely what dependencies (all of them) are being used. This is why I developed the dependency tracker plugin. The existing dependency plugin offers a few goals – tree, analyze – to help with dependency management, but to me it fails short in two ways.

First it is difficult to assess what has changed from one tree to another. It is let up to the developers to do a mental diff. The dependency tracker plugin creates to this effect a text report that can and should be commited along side your project's source code. As it is a text report it is very easy to see changes between revisions using your VCS of choice or you IDE.

Second, it is a manual process. Developers have to actively use the plugin to understand and clean up their dependency tree. One idea of the dependency tracker is that it creates a text report that should commited alongside your source code. Then you can setup your project so that every build checks that its dependencies are the same as expected and fail if there is the slightest difference.

Using the plugin

The dependency tracker has three goals:

report
validate
checksum

The two first goals work together. I'll come back to the 'checksum' goal later. First you want to create a report. One report will be created for each module of your project in a dependencies.txt file. Its format is the following:

dependency|dependency trail|artifact checksum|pom checksum

Where dependency denotes the dependency we are talking about, the dependency trail is the information about how the dependency is reachable in the dependency tree and the checksums speak for themselves.

Then you just have to configure the plugin in your pom.xml to validate the report on each build. But don't forget to commit the report first.

<plugin>
  <groupId>com.atlassian.maven.plugins</groupId>
  <artifactId>maven-dependency-tracker-plugin</artifactId>
  <executions>
    <execution>
      <goals><goal>validate</goal></goals>
    </execution>
  </executions>
</plugin>

You're done. If any of your module's dependency changes unexpectidely, your build will fail.

The checksum is there to help calculate checksum of arbitrary files as done by the plugin in reports. Simply use that command:

mvn dependency-tracker:checksum -Dfile=/path/to/the/file

The plugin is available in Atlassian's public maven repository.

Cleaning one's maven 2 local repository

2009-12-27T08:00:00.002+11:00

Maven 2's local repository has a tendency to grow, and never shrink. This morning mine was 2.2Go big.

There are not many things you can do to remve unused items from that local repository. You'd first have to know what's unused?
I tend to simply delete my local repository altogether from time to time. Only when I am ready to wait a little while during the next build though. I usually to that at work as there we have a local proxy that makes things pretty seemless.

There is also the growing number of SNAPSHOTs that are produced and dowloaded by maven builds. They are easier and safer to get rid of. Here is a simple unix command to clean up your local repository of SNAPSHOTs:

find ~/.m2 -name *SNAPSHOT -type d | xargs rm -rf

Holiday season

2009-12-26T09:20:00.005+11:00

Happy X-mas, holidays, whatever you believe in!

The holiday season is awesome on the web. This is the one time of the year when I hear about all the services I signed-up for and never got back to. Man there are quite a few of them. At least with all their 'holiday' mails, I can easily unsubscribe, delete my account, one at the time.

The maven dependency plugin

2009-05-10T17:06:00.016+10:00

The maven dependency plugin is amongst the most useful maven plugin. Every developer using maven2 should know the basics of this plugins.

What most developers like about this plugin is its very helpful goals to understand project dependencies. I am obviously talking about the dependency:resolve, dependency:tree and the various dependency:analyze goals. But this is not what I want to talk about in this post. I want to talk about the dependency:copy, the dependency:unpack goals and their counterpart the dependency:copy-dependencies and dependency:unpack-dependencies goals.

I often get asked at work what the difference is between those goals apart from the configuration syntax of course.

The major difference is that with one set of goals you specify which dependencies of the current module the plugin will act on while with the other set of goals you specify a collection of arbitrary artifacts. I know that doesn't sound like much of a difference until you understand about what maven calls the reactor.

To put it simply the reactor is the list of modules that maven is currently building. Maven for example uses the reactor to resolve in which order those modules should be built according to the dependencies they have on each other.

By now you probably understand better how those goals differ from each other. If you use the dependency:copy goal maven will not look in the reactor for the artifacts you want to copy. Therefore if you want to copy a module that is in the reactor you won't get the most up to date version (the one you are building right now) but a possibly completely out dated version coming from a repository somewhere. Another drawback is that the build will fail until the artifact exists in a repository somewhere (including the local repository). That is especially annoying if this artifact is the output of a module in the reactor of your current build and you're trying to build it for the first time.

On the contrary if you use the dependency:copy-dependencies goal you have to declare the artifact you want copied as a dependency. It means that you will get the artifact as you just built it - if it is part of the current maven reactor.

There is a definite advantage using the -dependencies version of those goals as then you make the most of maven strength in managing builds with inter-dependent modules. My rule is: whenever you can you should depend explicitly on a library using maven's dependency mechanism. This makes your build stronger and easier to understand.
Implicit dependencies on libraries through plugins makes things less obvious and harder to debug when a problem arises.