<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE concept PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd">
<concept id="about_ant"> 
  <title>What is Ant?</title> 
  <shortdesc>Learning about the blurred line between code and documentation and why
  technical writers need to learn Ant.
  </shortdesc>
  <prolog>
  <author>Rob Justice</author>
    <metadata>
      <keywords>
        <indexterm>Ant</indexterm>
      </keywords>
    </metadata>
  </prolog>  
  <conbody>
	 <p>If your DITA authoring tool uses the Open DITA Toolkit to generate your
		documents, you're already using Ant. So, what is Ant, anyway? Ant is a 
		<i>build tool,</i><i> 
		</i>a program used to compile other programs. If you work as a writer in
		the enterprise software industry, you know that software engineers regularly
		produce several versions of whatever software they are working on before they
		release it to the public. Each compilation is called a 
		<i>build</i>. Dozens, sometimes hundreds, of builds are compiled before
		the RTM (release to manufacturing) or GA (general acceptance) build is
		certified as the official release build. You can often determine the release
		build of whatever software you are using by reading the Help-&gt;About dialog
		box. For example, my version of XMetal is 5.5.0.219. This means that
		build 219 was the official release build for XMetal, version 5.5. 
	 </p> 
	 <p>Writers also draft, write, revise, and rewrite their documents many
		times before releasing a document to the public. We tend to call these drafts,
		rather than builds. You probably saved drafts of your documents in a
		document repository or CMS, a content management sytem, in the past, but I doubt
		you thought of your draft, even though it was versioned by the repository, as a
		software build that either compiled or failed to compile. A successful document
		"build" meant only that a document opened in your authoring tool the next day,
		not that all the related documents also opened successfully and "compiled"
		together to produce a version, albeit incomplete, of the documentation that
		will eventually make its way to your readers. Hence, the "build" metaphor did
		not extend beyond the programming code in the engineers' cubicles to the
		documents crafted by the writers. 
	 </p> 
	 <p>DITA changes that forever; the build metaphor is as relevant to you as
		to the engineers. Behind the user interface of your authoring tool, the
		DITA Open Toolkit uses Ant to compile a build every time you try to generate
		your single-source documents. If you want to customize the way DITA-OT
		generates your documents, you will need to open the hood, so to speak, and get your hands dirty
		with the internals of the Toolkit and Ant. 
	 </p> 
  </conbody> 
</concept> 