ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Atluri, Vamsi NYC" <>
Subject RE: ANT Capability
Date Thu, 28 Feb 2002 20:43:11 GMT

Ive tried the following and yet - I am not getting the correct results

<property name="cfnSrc" value="\cfn\core\citco\java\com" />
<property name="buildCfn" value="\build\cfn" />
<property name="JList" value="d:\scripts\cfn" />

<target name="compile">
 <!-- Compile the java code from ${src} into ${build} -->
 <javac srcdir="${cfnSrc}" 


 +Target: init
   +Task: tstamp
   +Task: mkdir
 +Target: compile
   +Task: javac
Build sequence for target `compile' is [compile]
Complete build sequence is [compile, init]
FileSet: Setup file scanner in dir D:\cfn\core\citco\java\com with
patternSet{ i
ncludes: [] excludes: [] }


Total time: 4 seconds

I am totally lost :(

-----Original Message-----
From: Diane Holt []
Sent: Thursday, February 28, 2002 2:48 PM
To: Ant Users List
Subject: RE: ANT Capability

--- "Atluri, Vamsi                NYC" <> wrote:
> So - All i have to is
> Define a property for bean.txt 
> <property name="JList" value="${cfnDir}\bean.txt" />

Oops -- guess my side note about the hard-coded full-path directory name
got things a bit confused? I only meant that as a "better practice" kind
of thing. In other words, it's usually better not to have a hard-coded
full-path down in some attribute of some task in some target somewhere in
the buildfile -- but rather, to use a property, either in some block of
property defines for directory locations or in a properties file that gets
read in with a <property file="..."/>, since this makes for easier
maintainability. But it doesn't have anything at all to do with how the
<javac> task reads file names from an includes file.

> I guess it my lack of unserstanding of how javac works - Doesnt it
> expect java file to be in the 'srcdir' rather than a txt file - Or does
> it know that it should read from the txt

I does in fact look for the source files in 'srcdir' (or, more usually, in
subdirectories of 'srcdir'). But you can tell it to only look for specific
source files in one of three ways:
  - Specify the 'includes' attribute, listing a file name or
    comma-separated list of file names.
  - Use nested <include name="..."/> elements, where 'name' is
    either a single file, or a wild-carded specification.
  - Put the files you want <javac> to deal with in a text file,
    listing the file names one per line, either as a specific
    file or as wild-carded specifications, then use either the
    'includesfile' attribute, or the <includesfile name="..."/>
    nested element, to point to that text file.

If you don't use one of the above, but simply specify a 'srcdir' and a
'destdir', <javac> will recurse through 'srcdir', looking for any and all
.java files -- so, unless there's some reason you need to limit what files
<javac> will compile, you can just let it scoop up all of them.

If you do need to limit which source you want to be compiled, and you
choose to use the third method above (which you seem to want to do), the
text file can be thought of as an alternative to using nested <include
name="..."/> elements. In other words, the following two <javac> tasks are
completely equivalent:

[Using nested <include> elements]
<javac srcdir="${src.dir}" destdir="${classes.dir}">
  <include name="com/atluri/io/"/>
  <include name="com/atluri/tools/parser/*.java"/>
  <include name="com/atluri/utils/**/*.java"/>

[Using an external text file to specify included source files]
<javac srcdir="${src.dir}"

$ cat bean.txt

Note that there is -no- difference in what <javac> will do(*), whether you
use the first example or the second -- it will still limit its search for
the .java files (and their corresponding .class files) to those specified.
Which method you use is completely up to what best suits your needs. If
you envision the list of source files you want compiled changing on a
fairly frequent basis, then it probably is more reasonable to use the
external text file to list the files, since that way there's less mucking
with the build.xml file itself.

(*) Other than additionally reading in the text file to obtain the list

Hope this clear things up.



Do You Yahoo!?
Yahoo! Greetings - Send FREE e-cards for every occasion!

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

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

View raw message