On Tue, Sep 1, 2009 at 3:29 AM, Francis GALIEGUE <f...@one2team.com> wrote:
> OK, this is a clear enough explanation. I'm not really sure about the
> "programming language vs build system" analogy, though ;)
>
> I think I still don't have "the ant way" of doing things even though
> I've been using it for several years now...
>
> Sorry for the waste of time,
>
No waste of time. It take a while to get use to the difference between a
build system vs. a program paradigm.
A build system is hard to comprehend because we are so use to looking at the
problem as a programmer. We know what we want done in what order and our
instinct is to tell Ant exactly how to do this. The "if" and "unless"
parameters of the <target> seem to enforce this mode of thinking.
Here's a small example on the difference between looking at Ant as a program
language vs. a build system. I need to build and deploy a jar file. My first
two targets will look like this:
<target name="compile">
<blah, blah, blah/>
</target>
<target name="jar" depends="compile">
<blah, blah, blah/>
</target>
The question is what should my deploy target look like?
1. <target name="deploy" depends="*jar*">
<blah, blah, blah/>
</target>
2. <target name="deploy" depends="*compile,jar*">
<blah, blah, blah/>
</target>
The difference is in their dependency listing. The developer in us wants to
do "1" (and even make sure we list "compile" before "jar" in the depends
list too!). Simply stating that we need to deploy the jar makes our little
developer brains think of all the steps from "A" to "Z" that are needed.
However, the correct answer is really "2". Deployment doesn't care about the
steps to build the jar. It only cares that there is a jarfile. In this
simple case, it really doesn't matter because the resulting build process
will be exactly the same. However, as the build gets more and more complex,
trying to determine the exact build order gets more and more difficult.
Take a look at your build process as independent tasks, and some of those
tasks depend upon the output of other tasks. Try not to think of all the
various steps you need to get to a particular task. Just the task and what
that task needs in order to perform that task.
Previously you had three targets:
<target name="converage-report">
<target name="converage-report-gen">
<target name="converage-report-mail">
I take it that you also have some sort of target called "build" or something
similar that depends upon the coverage report:
<target name="build" depends="compile,jar,coverage-report">
However, this is actually not true! Your build isn't dependent upon the
coverage report! That's why you want the option to skip it. What you should
do is remove the dependency on coverage-report from your build target. If
you want a coverage report, you simply call both targets:
$ ant coverage-report build
Don't like the idea of calling two targets? Define a faux target that
depends upon the build and the coverage report.
<target name="build-with-report"
depends="build,coverage-report">
Now, to build with the coverage report, I simply specify this new target:
$ ant build-with-report
An advantage is that you can use the "description" parameter of the <target>
task to specify what that target does:
<target name="build-with-report"
depends="build,coverage-report"
description="Builds system and produces coverage report">
Now your developers can use "*ant -projecthelp*" to see the various build
options:
$ ant -projecthelp
Buildfile: build.xml
Main Targets:
build: Builds the system
clean: Cleans out all built artifacts
build-with-report: Builds system and produces coverage report
Default target: build-with-report
This way, you're actually documenting the way to build the project without
producing the coverage report inside the build.xml file itself.
--
David Weintraub
qazw...@gmail.com
