These instructions are a way to do conditional compilation with Java like the C/C++ #ifdef. In Java there is no preprocessor and so we need to work around this missing feature. This work around is using Ant's copy and filter feature to create the source with the different code in it.
I feel obligated to add some corrections to my original email to avoid confusions and distress by the developer of Maven 2 because any open-source developers deserves respect for the time and effort he/she spends on such project help all of us.
Lately I was made to look into Maven 2 and started wondering why so many complete rewrites of popular open-source projects never make it. In my view it comes down to the resistance of people to changes which has nothing to do with software development at all.
I do not like legal discussions or disputes because here in the US it is quite often big money against little money and as a single person you are silenced by big corporations' power. I also know that I go on a slippery slope here but I think it is important for all of us to know where and how the name Java can be used and why some 'entities' can use Java in their name and other do not.
I started to love Maven not only for its scripting abilities but also for the fact that one could start a simple project in a few minutes which is even faster than to build a project with shell scripts. So if you are in doubt about Java just create a simple Maven project and test it with life code.
In one of the comments to the original blog about Unit Tests I was told that tests can never be as important as the code itself. I want to use this opportunity to explain a little bit more why I still think that developers should pay way more attention to testing even thought that test code is not delivered and/or sold.
During a discussion with a colleague we started talking about the problems of equals() with inheritance. He mentioned Joshua Bloch's Effective Java book which covers this topic quit well but more or less said that this problem cannot be resolved. This was enough to get me hooked onto this problem and I came up with a solution quite fast.
I know that probably backward compatibility is the main reason to keep java.lang.Cloneable as it is. Nevertheless as I hopefully showed in my rant about this still unresolved issue this shortcoming of the Cloneable interface is still haunting us.
I cannot remember when I complained about the missing public Object clone() method in the java.lang.Cloneable interface for the first time but in the latest release of Java (1.5) this bug hurts us developers even more.
Tom talked in The Problem with Unit Testing about Unit testing. Even though that I agree with most of it I disagree with the view that Unit Testing is only a safety net. The only person responsible of the quality of the software is the author himself and he/she should be held accountable for that.