ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Fuller <>
Subject Re: Antcall Vs. macrodef
Date Wed, 25 May 2005 15:41:25 GMT wrote:

>Hi folks,
>I am writing a common build script for 2 departments that build similar
>products but have some slightly different requirements in terms of build
>My plan was to have modular independent functions so that the common
>functionality could be used by both teams and the different functions can
>be called as separate targets.
>In this case, is it generally considered preferable to use the antcall or
>macrodef? If the answer is "it depends" what are the circumstances in which
>one would be preferable over the other?
a few general comments, all my own opinion;

- macrodef has generally better perf
- macrodef and presetdef are indeed perfect for creating modular
independent functions

- constrain macrodefs to task level activity, going beyond this e.g.
encapsulating an entire sequence of tasks in a macrodef means it cant
easily participate in dependencies (using depends or std
if/unless)...dont use a macrodef instead of a target as a reuse
mechanism across dept.

- macrodefs should be thought of as perfect reuse structures across
different Ant it should be more generic in nature, use
presetdefs if you are looking for intraproject 'comfort'...u should also
put macrodefs seperate into antlibs

- try to keep your 'differences' located in properties between
departments and override by replacing/supplying different properties...u
can achieve this by either using different property files, or giving a
different run script wrapper to ant, which sets up env and supplies
properties at ant commandline

- parameterising your projects with properties is the first step of
refactoring, the next steps are to ask questions like; are the
differences between departments in dependencies (do they use different
libs), are development environments different, do they work off same
source code branch, do they deploy to different targets,

Also if the projects are enterprise in scale, I would suggest just
having 2 independent Ant builds at first...instead of trying to get some
gains through may find that trying to figure out the best
way forward through the intersection of 2 projects more difficult to
solve with effectively one build script, no doub this a magnitude more
difficult chore then just having 2 scripts.....which perhaps over time
converge every once in a while through refactoring; perhaps sharing a
common antlib(s) and structure.

you should take a look at the ant_in_anger document included in the
manual for Ant..

gl, Jim Fuller

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message