Ambient orb build task

Finally it's possible to hook up an orb to your Ant build.

Keep it on the Green

Recently, Martin Fowler updated his Continuous Integration paper, "For most projects, however, the XP guideline of a ten minute build is perfectly within reason. Most of our modern projects achieve this. It's worth putting in concentrated effort to make it happen, because every minute you reduce off the build time is a minute saved for each developer every time they commit. Since CI demands frequent commits, this adds up to a lot of time."

"The commit build is the one that has to be done quickly, as a result it will take a number of shortcuts that will reduce the ability to detect bugs. The trick is to balance the needs of bug finding and speed so that a good commit build is stable enough for other people to work on."

"A simple example of this is a two stage build. The first stage would do the compilation and run tests that are more localized unit tests with the database completely stubbed out. Such tests can run very fast, keeping within the ten minute guideline. However any bugs that involve larger scale interactions, particularly those involving the real database, won't be found. The second stage build runs a different suite of tests that do hit the real database and involve more end-to-end behavior. This suite might take a couple of hours to run."

Breakage patterns for a build is listed in, "Avoiding Continuous Integration Build Breakage Patterns" it includes: "Five O'clock Check-In", "Spoiled Fruit" and "It Is a Small Change".

The overall effect of having a slower build is that tested user visible functionality becomes more difficult over time. Each new high level test increases the build time and understanding what has broken takes longer. Often time is not taken to ensure that your faster atomic/unit/integration tests cover what was missing. So the importance of maintaining a green build when you have worse feedback becomes more important but the cost of maintaining it becomes more expensive.

Some of the discussion that I've had is on this thread on the boost mailing list.

Raving about Maven

So for every pro-Maven story I've seen I get, For F___ Sake, why does maven suck so much "On a more specific note of why I hate maven. The first one is the whole idea of maven repository. I agree that maven repo works if things are simple and the jars aren't changed that often. For all other real world cases where jars or versions change rapidly, maven often fails to update the repo. When that happens maven just craps itself. What's worse if one's network connection is buggy and unreliable. having a remote repo is worth crap when the network blows. Sure, one can setup a local repo, but what if the LAN is unreliable."

"Overriding build.properties is a bitch if one has lots and lots of properties. Say I have an EJB that is built nightly, but new branches are created every month. What if I need to test different branches on an on going basis? Well with ANT I can pass it a different build.xml file. With maven I haven't been able to find a way to do, I don't believe it can be done. It would be great if i could start maven and point it to say branch2build.properties instead of build.properites."

From what I can tell this is Maven 1, whereas Maven 2 is apparently a lot better.