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