Ant build best practices - Forum - OpenEdge Development - Progress Community

Ant build best practices

This question is not answered


I'm looking for input/guidance/best practices on creating build.xml files and associated properties for building ABL applications (or even just the ABL that we ship). I plan to use PCT for the ABL-specific things.

- granularity of the XML files: should i just have xml to rule them all?

- common stuff: certain tasks can be generalised with parameters/conventional-folder-locations. Is this a  good idea, or should each project be completely self-contained?

- anything else?

All Replies
  • If you can share certain tasks between the projects i see no reason to not create one big build.xml file

    If it turns out to not work for some reason, it should be easy to split it again.

  • When setting up the development / ops workflow I found particularly useful to load any environment specifics from an external property file. When moving from dev to test to acceptance and production we use the exact same (build.xml) script, which itself is actually stored in the same SCM repo as the rest of the sources.

    As of the granularity, I would advise to only split files if part can be re-used. Navigating back and forth between different is not as easy as normaly with source code and a good editor, so sometimes you get lost if there's more than 1 or 2 .xml files involved (of maybe that's just my aging memory).

  • Hi Guyz,

    I am also in learning of Ant jobs. I started with small ant jobs and it works for me. But for few jobs I am facing issues such as I am not able to pass the progress startup parameters ( -h, -inp, -T etc ) to the build xml. Do you guyz have any idea on this ?

    Or what is equivalent to these parameters in build.XML ?

  • I've also put external jars in a central properties file, for example:



    These are then used as

    <property file="${src}/" />

    <taskdef uri="antlib:eu/rssw/pct" resource="eu/rssw/pct/antlib.xml" classpath="${src}/${pct.jar}" />

  • I use a set of property files and the fact that properties are immutable to handle os / phase differences

    <condition property="osname" value="linux">

            <os family="unix" />
        <!-- if it's not unix assume it's some kind of windows, enhance the section above if this is no longer true -->
        <property name="osname" value="windows" />
        <property name="phase" value="development" />
    <property file="${wst.basedir}/build.props.${osname}.${phase}" /> <property file="${wst.basedir}/build.props.${osname}" /> <property file="${wst.basedir}/build.props" />

    • build.props contains the defaults
    • windows specific properties such a graphicalmode=true
    • : e.g. the assemblies directory used for development
    • e.g. the assemblies directory used for production

    I move reusable macros such as compiledirectory into a separate file