ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Azariah Jeyakumar" <>
Subject RE: Including a common build file with common targets.
Date Tue, 16 Oct 2001 18:12:15 GMT
We had a similar situation. We had only a partial solution which I will
describe here:
The targets are split into targets that do actual work and targets that are
useful only for sequencing. For example, we had targets like:
clean - cleans
compile - compiles
jar - jars
docs - creates javadoc
build - compile and jar
rebuild - clean, compile, jar
all - clean, compile, jar, docs
The build, rebuild and all targets are sequencing targets. They are
identical in all the build files, so they are defined in the common file.
The targets that do the actual work also looked 'almost' identical but since
they were slightly different in some build.xml files, they were defined in
the individual build files. I guess some more improvising could have been
done to further factor out common code.
BTW, I believe that it is a common requirement to factor our common code
especially in large projects where several people are working on it. I have
seen suggestions like using file, but it can only factor
out properties. We need to be able to factor out everything: filesets,
targets, etc.

-----Original Message-----
From: Albertus Vermeulen []
Sent: Tuesday, October 16, 2001 8:30 AM
To: ''
Subject: RE: Including a common build file with common targets.


Please excuse my ignorance if I don't quite understand all the power that
Ant provides me. I'm not sure that I follow your comments exactly but I can
explain to your why I thought that <ant> wouldn't quite work for me.

The end effect I'm trying to achieve is as follows. In any project that a
developer is coding one build.xml file should exist. I haven't mapped it yet
to exactly what it should look like in ant but probably something like:

<project name="QuoteSystem"> 
  <property environment="ENV"/> 
  <property name="MODULE_VERSION" value="1.1.14"/ 

  <property name="MODULE_DEPENDENCIES" value="list of jars that this project
depends on. Used to setup classpath. This is though not a full path,
manipulation needs to happen in common.xml"/>

  .... include common file which defines all targets and rules for compiling

    idl,java,pcml (something specific in our environment), etc something to
the effect of .... 
  <include ${ENV.DEVELOP_HOME}/common.xml> 

As I understand, by using <ant> as was suggested to me by Jerry Li, I would
need to for each target (17 in total) have to do a replecation of the
<target>s defined in common.xml in the above build.xml. I would thus save on
not having to expose the body of the target in the above file or the
properties I need to achieve the completion of the target, but I would still
add a lot of extra targets in the build.xml file. I also seemed to
experience some difficulty in accessing properties declared in the build.xml
file within the common.xml file. This could though just be a clear case of
me not having RTFM'd enough yet. :)

Am I wrong in my understanding of how <ant> can/should be used ? Is there
some way in which I could achieve what I described above ?

Thanks in advance 

-----Original Message----- 
From: Diane Holt [ <> ] 
Sent: 16 October 2001 04:19 
Subject: RE: Including a common build file with common targets. 

--- Albertus Vermeulen <> wrote: 
> Thanks for your input, your solution would mean less lines in the 
> build.xml files, but doesn't really provide me with the solution I'm 
> looking for. I'm really looking for an equavalent of include in 
> makefiles. In our development environment we have seperate components 
> that developers are working on. They all need to make the same targets, 
> but for their own projects. We currently maintain these "make" targets 
> in one file and this ensures that there is very little clutter in the 
> Makefiles of each developer. This can't be changed when we move to Ant. 

Can you explain a bit more why using the <ant> task won't work for you? I 
have a "common" target (eg.) for building parsers in my "main" build.xml 
file that lives at the top of the user's workspace (which can be 
anywhere). Building a parser in a sub-buildfile <ant>'s the common parser 
target, passing the properties it needs to use.  That sounds like what 
you're looking to do, but maybe I'm missing something. 



Do You Yahoo!? 
Make a great connection at Yahoo! Personals. <>  

View raw message