Ant build best practices

Posted by Peter Judge on 29-Jan-2018 15:30

Hi,

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

Posted by doa on 30-Jan-2018 02:34

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.

Posted by bronco on 30-Jan-2018 02:52

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).

Posted by atuldalvi123 on 30-Jan-2018 03:11

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 ?

Posted by Stefan Drissen on 30-Jan-2018 06:19

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

pct.jar=other/eclipse/pct/pct-208.jar

sonar.jar=other/eclipse/pct/sonarqube-ant-task-2.5.jar

These are then used as

<property file="${src}/version.properties" />

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

Posted by cverbiest on 30-Jan-2018 09:21

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" />
    </condition>
    <!-- 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
  • build.props.windows windows specific properties such a graphicalmode=true
  • build.props.windows.development : e.g. the assemblies directory used for development
  • build.props.windows.production: e.g. the assemblies directory used for production

I move reusable macros such as compiledirectory into a separate file

This thread is closed