ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kyle Adams" <>
Subject Build script design issues
Date Tue, 26 Jun 2001 15:52:11 GMT
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 (${} for example) would be used
to load a configuration file (${}.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.


View raw message