ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dominique Devienne <>
Subject RE: The Elements of Ant Style
Date Mon, 22 Apr 2002 18:52:52 GMT
FYI: Replied on ANT-dev only the first time. Here it is again for ANT-users:

I'm not sure it's the best way, but one thing you can do is have an external
manifest file used inside of <fileset> of <copy>. In general, resource files
have the same relative path in source and destination directory (as seem to
be the case of your sole example file), so the manifest file solution works.
If you need to flatten the hierarchy, you can use of <mapper> in <copy>, but
if you copy files from/to unrelated relative paths, then you're stuck with
individual <copy file="" tofile="">.

So if you have these files:


that need to go in 


you can have a manifest file resources.manifest with the following listing
(note that the patterns are relative to the dir attribute of the <fileset>,
and don't try to match against the absolute filename, if I understood Diane
correctly a while back):

That you use in your build.xml as follows:

<copy todir="${builddir}/classes">
  <fileset dir="${srcdir}"
           includesfile="resources.manifest" />

If you have many such properties files in your package hierarchy, you
probably want to include all of them in your manifest (or build.xml
directly) with an ANT-regex:


It's not clear from the doc on <copy includesfile="" /> whether the include
file is relative to ${basedir} or not, so either prefix it with ${basedir},
or use an intermediate <property name="" location="resources.manifest" /> to
reference it.

Haven't tested what I'm describing here, but I think it should work. Hope
this helps. --DD

-----Original Message-----
From: Steven Newton [] 
Sent: Monday, April 22, 2002 12:01 PM
To: Ant Developers List;
Subject: RE: The Elements of Ant Style

Is there a better way to have ant handle the copying of properties
files that are part of the build dependency than simply adding a
list of the files to copy?  Right now I have:
<target name="properties" description="copy properties and taglib definition
    <copy file="${srcdir}/"
    <!-- lots more lines like this one -->

Is there a better style recommendation for this sort of task?

Also, better notes on using the <available> tag to set up the 
build environment dynamically!


> -----Original Message-----
> From: Erik Hatcher []
> Sent: Thursday, April 18, 2002 5:22 PM
> To: ant-dev;
> Subject: The Elements of Ant Style
> The Ant book that I'm co-authoring is entering its last phase 
> of development
> and we would like to involve the entire Ant community in our 
> efforts. The
> primary reason for doing this is because its fun and gives folks an
> opportunity to be a part of something we feel is very special.
> One of our Appendices is titled "The Elements of Ant Style" 
> in honor of my
> most favorite Java book of all time, "The Elements of Java 
> Style". We want
> to make our Ant version similar in that it will be an 
> organized collection
> of Ant words of wisdom and little gems of advice to make our 
> build file
> writing that much better and elegant.  Here is an example:
> - Build paths up from previously defined properties rather 
> than directly.
> Don't do this:
>   <property name="build.dir" location="build"/>
>   <property name="build.classes" location="build/classes"/>
> Do this instead:
>   <property name="build.dir" location="build"/>
>   <property name="build.classes" location="${build.dir}/classes"/>
> Which would be followed by a brief explanation of why, which 
> in this case is
> so that you can override the value of build.dir and it will 
> in turn affect
> all subordinate mappings (and of course the subordinate 
> mappings could be
> reassigned individually if desired too in either case).
> Here's what we are asking: Submit your gems of Ant wisdom 
> (they should be
> short and sweet, for the most part) to 
> or
> reply on the ant-user list. We will use our discretion for 
> which entries are
> accepted, and there are no promises that entries submitted 
> will be used. If
> you would NOT like your name attributed to the entry, please 
> state this in
> your submission, otherwise we will give you the attribution 
> (name only, not
> e-mail address) - be sure the name you want attributed is in 
> your e-mail
> header or stated in the text of your mail. The first to 
> submit a particula
> item (as there is likely to be duplication) wins.
> The publisher posts complete sample chapters on their 
> website, and we will
> push to have this Appendix be one of them so that it is 
> freely available to
> the community - no promises as that is not within my direct 
> control though.
>     Erik Hatcher
>     Steve Loughran
> --
> To unsubscribe, e-mail:   
> <>
> For additional commands, e-mail: 
> <>

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

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

View raw message