I'm beginning to learn Ant in order to convert old (but working) make files and batch
scripts. I'm working in a large corporate environment, where we have multiple
web-apps utilizing J2EE technologies. These applications all make up one website used
for various corporate functions (customer management, product management and internal
support). Thus, there is one project (the internal corporate website) with several
sub projects (each application). Our situations falls under Steve Loughran's
"Integrated sub projects" section in "Ant in Anger: Using Ant in a Production
Development Systme".
I've gone over a number of the articles linked to from the Ant resources page,
including the short tutorial on Ant for the Cactus project, and the "Ant in Anger"
paper.
I'm now struggling with proposing a best-practice methodology for implementing Ant
scripts in the build process. The papers I've read seem to lean towards multiple
build.xml files at various levels in the application structure, with higher-level
build files delegating tasks to lower level build files at various points.
Yet this approach seems to duplicate the same workflow over and over again for each
sub project, ie., the build task is basically the same for each sub project. Another
approach that I've considered is creating one "template" build.xml file. This would
be wrapped by a script that take (via command line) the name of the application the
developer wishes to build, and pass it on to the template build file. This variable
(${project.name} for example) would be used to load a configuration file
(${project.name}.properties). This would allow for "plug-n-play" of new applications
- simply create a new configuration file for the new application. Right now I'm
leaning towards this approach.
On the other hand, I have no experience with using ant on a large-scale project. I'm
hoping some of you with more experience in this will be able to advise as to what the
best (most efficient, scalable, flexible, easy-to-maintain) approach is.
Kyle
