Using Team Build for Java builds that use Ant

July 2007 - We're a Java development group using TFS. You're probably asking why a Java development group would buy TFS, which is a valid question. The answer is quite long and complicated (political), so I'll save the gory details for a future post. In short; though my group uses primarily Java, a group across the hall, which is equally sized, uses .NET. We're a fairly large software company who was looking for a cost effective solution that would satisfy both Java and .NET developers. After evaluating the array of offerings, TFS offered this for us.

To compile our Java code we use Ant exclusively and Anthill Open Source as a high-level driver to kick off the builds. If you're interested in using Anthill Open Source to talk to TFS, I hear there is a friendly open source developer ;) who has written an adaptor for you.....

Anyway, we really wanted our builds to list out the work items linked to changesets included in each build. Team Build gives us exactly what we want, but again we're a Java shop using Anthill. How can we use Team Build to run our Ant scripts?

We (actually my wonderful configuration management colleague who deserves all the credit for figuring this stuff out) had to override the "CoreCompile" target in our TFSBuild.proj file so we have control of what "compile" means for us. The full list of things "CoreCompile" does is located in the "microsoft.teamfoundation.build.targets" file. Since "compile" to use means call ant, we can override "most" of that stuff.

I say "most" because we do need to call MSBuild. If we don't, build results are not published to the data warehouse. This is a bit lame, but after we all got done cussing and swearing at Microsoft (remember we're a Java development group and take every good natured opportunity to bash Microsoft), we simply created a blank solution file, placed it next to our build.xml in source control and called it. The only two lines in the solution file are "Microsoft Visual Studio Solution File, Format Version 9.00" and "# Visual Studio 2005". It does nothing more than somehow signal Team Build to publish our results in the data warehouse.

After we get done calling the superfluous MSBuild task, we do the real work. We use the Exec task to call Ant with the needed parameters. Lastly we copied over the OnError task from the main "CoreCompile," which will execute the "OnBuildBreak" task in the master targets file (i.e. microsoft.teamfoundation.build.targets).

I don't consider this an optimal solution, but a step in the right direction. Our current Anthill solution has a nice feature where it will only build if there are changes. Team Build fires away every night, which ends up creating a number of needless builds. We also frown every time we setup a new project and have to put a blank Solution File next to the build.xml. Again, we get over it with a afternoon coffee and obligatory Microsoft bash session (all in good fun of course).

So if you're a Java group using TFS, give Team Build a try. It seems to be working fine for us, and once Orcus gets here Team Build should have a number of additional features (e.g. continues integration builds) that you'll want to take advantage of.

<Target Name="CoreCompile">
<TeamBuildMessage Tag="Configuration" Value="%(ConfigurationToBuild.FlavorToBuild)" />

<MSBuild Condition=" '@(SolutionToBuild)'!='' "Projects="@(SolutionToBuild)" Properties="Configuration=%(ConfigurationToBuild.FlavorToBuild);Platform=%(ConfigurationToBuild.PlatformToBuild);SkipInvalidConfigurations=true;VCBuildOverride=$(MSBuildProjectDirectory)\TFSBuild.vsprops;FxCopDir=$(FxCopDir);OutDir=$(OutDir);ReferencePath=$(ReferencePath);TeamBuildConstants=$(TeamBuildConstants);$(CodeAnalysisOption)" Targets="Build" />

<Exec Command='ant -f "$(SolutionRoot)\ant\build.xml" -Dappdeploy_nightly="true" -Dversion=0.0.0.0'>
<Output TaskParameter="ExitCode" ItemName="ExitCodes"/>
</Exec>

<OnError ExecuteTargets="OnBuildBreak;" />
</Target>