ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phillip Lord <>
Subject Re: Generic template for software build plan
Date Thu, 19 Dec 2002 18:05:01 GMT
>>>>> "Nicola" == Nicola Ken Barozzi <> writes:

  Nicola> Phillip Lord wrote: [...]

  >> I'm still not sure. Centipede looks nice, and might do some of
  >> what I want, but its looks a lot more complex. I had a look
  >> through the wiki, but I couldn't find anything concrete
  >> describing what "the embed proposal" that you refer to, actually
  >> does. With my system, you just take the defined build file, and
  >> just

  >> override the bits you don't like. All the rest comes for free. I
  >> can still use my XML aware editor to do correct tag placement, as
  >> the individual project build files are just ant files, and most,
  >> although not all of the code duplication between projects that I
  >> have had in the past with ant disappears. And it works with any
  >> build file, including third party ones over which I have no
  >> control, which is useful for me. I'm not trying to convince you
  >> here. I wrote antmerge, because I

  >> needed something like it. My solution is cheap and cheerful. The
  >> code base is fairly small. And it mostly works. If people want to
  >> use it they are welcome to it, and if they don't, then this is
  >> fine also. If there is alternative which is better, then I'd like
  >> to know, because if I can spend less time doing my build, and
  >> more time developing the "end product", well thats good for me.

  Nicola> :-)

  Nicola> I'm trying to "sell" you the embed proposal because there is
  Nicola> a >0 possibility that it will go in the Ant codebase. Part
  Nicola> of it is being moved-intergrated in these days.

  Nicola> I'm just trying to understand id AntMerge does something new
  Nicola> I might be interested in for Centipede, and possibly work
  Nicola> together.

  Nicola> Here is how you can simply "override" as you say using the
  Nicola> embed proposal or Centipede:

  Nicola> you make a file called mybuild.xml and you can override it
  Nicola> in build.xml:

  Nicola> <project name="mainbuild" default="all" basedir=".">

  Nicola>     <import file="mybuild.xml"/>

  Nicola>     <!-- all targets define here override the ones
  Nicola>          in mybuild.xml -->

  Nicola>     <!-- The ones not overridden are available -->

  Nicola>     <!-- You can all the parent target with
  Nicola> (IIRC) -->

  Nicola> </project>

  Nicola> Is this what AntMerge does?  You can also import more than
  Nicola> one file too.


You can over ride any tag, as well as targets, with antmerge, so long
as the tag is, what I call "uniquely identifiable", which means that I
can work out which one in the "super class" file, is being over-ridden
by the sub class. So, for example, from antmerge's own build file
(it builds its own build file), we have....

  <property name="jar-dependencies" value="xercesImpljar,xmlParserAPIs.jar,java-getopt-1.0.9.jar"/>
  <property name="antmerge.parent" value="default"/>
  <property name="antmerge.infile" value="antmerge-in.xml"/>

which over ride the properties set in the parent (you could clearly
also do this by loading a properties file). So these end up in the
generated build.xml, over-ridding the parent.   

Then we have....

neither procompile.test, nor exist in the parental

  <!-- check if any files are out of date -->
  <target name="precompile.test">
    <uptodate property="antfiles.uptodate"
      <srcfiles dir="${etc}">
        <include name="default-in.xml"/>
        <include name="antmerge.xml"/>

  <!-- if any files are out of date rebuild them all (ant makes it too
  much hard work to just rebuild the right ones) -->
  <target name="" depends="precompile.test"
    <exec dir="${etc}" executable="antmerge">
      <arg line="--mainfile=antmerge.xml"/>
      <arg line="--mergefile=default-in.xml"/>
      <arg line="--output=default.xml"/>
    <!-- the antmerge.xml file which this inherits from checks whether build.xml is
    out of date with respect to antmerge-in.xml. It doesn't check whether its out
    of date with respect to default.xml. Generally users of antmerge will not be editing
    default.xml, so this is not a problem. But this file has to do it explicitly -->
    <exec dir="." executable="antmerge">
      <arg line="--mainfile=${antmerge.parent}"/>
      <arg line="--mergefile=${antmerge.infile}"/>
    <echo message="antmerge internal build files have been regenerated"/>
    <echo message="as antmerge's own build file is generated by antmerge"/>
    <echo message="it's possible that the build is not complete, and you"/>
    <echo message="may want to run ant again"/>
but precompile itself does, although it has no dependencies in the
parental file. So we have hooked in different sets of targets. 

  <!-- we need to regenerate some build files -->
  <target name="precompile" depends=""/>

Finally you can uniquely identify any tag using, guess it, an id tag. 


  <property id="" file=""/>

in the parental file would be replaced by 

  <sleep id=""> 

in the child file. 

I haven't done multiple imports yet, but it's trivial to do (you just
do the merge repeatedly on one file after the other). 

This all sounds fairly obtuse, but I've played with it long enough to
know that generally it just does the right thing, and seems to make

My code is on the web, if you want to play with it. 



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

View raw message