You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ant.apache.org by vl...@trilogy.com on 2001/08/28 06:13:57 UTC

filesets referenced by 's element

I've been using things like the following [ant v1.4beta2]:

<javac destdir="..." >
        <src refid="idA" />
        <classpath refid="idB" />
</javac>

where if "idA" points to something like

<!-- option A -->
<path id="idA" >
    <fileset dir="${core.src.dir}" >
      <include name="**/*.java" />
      <exclude name="**/*.html" />
      ... and so on ...
    </fileset>
</path>

then <javac> barfs with a message that some file in my ${core.src.dir} is 
not a directory [the first file it finds during a recursive directory 
traversal, it appears]. Obviously, it tries to recurse into that file and 
that does not work, of course.

However, if I change my idA path such that it contains no nested 
<fileset>'s and only straightforward path elements, like:

<!-- option B -->
<path id="idA" >
    <pathelement path="${core.src.dir}" />
    ...
</path>

then it works. This forces me to move my includes and excludes into the 
<javac> task itself, while I 'd rather group my inclusion/exclusion 
patterns together with my path strucutres and reference it through a 
refid. After all, I'd like to think about my <javac> operatin on a fileset 
and I'd like to form such filesets elsewhere so I could re-use them 
throughout the file.

I don't understand why the option A does not work. According to <javac> 
documentation, "srcdir" is a path-like structure and is settable via 
nested <src> elements. This is what I am doing in both cases. Also, per 
documentation path-like structures are allowed to contain nested <fileset> 
elements, which is what I am doing in option A. Yet it does not work -- 
could someone explain why?

It appears to me that I should change my way of thinking: instead of 
<javac> being a target working with 2 filesets (srcdir, classpath, and 
bootclasspath) I am supposed to think of it as a source fileset (srcdir) 
that works with other filesets (classpath and bootclasspath). I don't 
quite see why the latter would be more logical.

Thanks in advance,
Vlad

Re: filesets referenced by 's element

Posted by Conor MacNeill <co...@cortexebusiness.com.au>.
The <src> identifies sources of java files - not the files themselves. To
understand this, you need to realize that the <src> elements are combined
to become the javac -sourcepath option. Here is the documentation for
the -sourcepath attribute (from
http://java.sun.com/j2se/1.3/docs/tooldocs/win32/javac.html)

-sourcepath sourcepath
Specify the source code path to search for class or interface definitions.
As with the user class path, source path entries are separated by
semicolons (;) and can be directories, JAR archives, or ZIP archives.

So, the files you put in the <src> path element must be jars/zips - not
individual java files.

While it is true that a path can contain a nested fileset, possibly
specifiying jars/zips, the <javac> task really expects these to be
directories. What <javac> then does is apply the <include/exclude> patterns
to all the source directories. In effect the <javac> task is overloading
the <src> element to specify the sourcepath AND the files to be compiled.
That behaviour isn't actually bad in most instances, but is probably the
root of your problems..

Note that the implementation of the <javac> task predates <fileset>s and so
that is why the documentation refers to an implicit fileset. Actually even
that is not quite true, it is more like an implicit patternset applied to
each source dir. As you can imagine introducing an explicit fileset for the
source selection may not be all that easy. :-)

So how to think of it. Think of <javac> as having an implicit patternset
applied over the source directories. Is that logical? Maybe not, but that
is the result of <javac>'s history and evolution.

Conor

----- Original Message -----
From: <vl...@trilogy.com>
To: <an...@jakarta.apache.org>
Sent: Tuesday, August 28, 2001 2:13 PM
Subject: filesets referenced by <javac>'s <src> element


> I've been using things like the following [ant v1.4beta2]:
>
> <javac destdir="..." >
>         <src refid="idA" />
>         <classpath refid="idB" />
> </javac>
>
> where if "idA" points to something like
>
> <!-- option A -->
> <path id="idA" >
>     <fileset dir="${core.src.dir}" >
>       <include name="**/*.java" />
>       <exclude name="**/*.html" />
>       ... and so on ...
>     </fileset>
> </path>
>
> then <javac> barfs with a message that some file in my ${core.src.dir} is
> not a directory [the first file it finds during a recursive directory
> traversal, it appears]. Obviously, it tries to recurse into that file and
> that does not work, of course.
>
> However, if I change my idA path such that it contains no nested
> <fileset>'s and only straightforward path elements, like:
>
> <!-- option B -->
> <path id="idA" >
>     <pathelement path="${core.src.dir}" />
>     ...
> </path>
>
> then it works. This forces me to move my includes and excludes into the
> <javac> task itself, while I 'd rather group my inclusion/exclusion
> patterns together with my path strucutres and reference it through a
> refid. After all, I'd like to think about my <javac> operatin on a
fileset
> and I'd like to form such filesets elsewhere so I could re-use them
> throughout the file.
>
> I don't understand why the option A does not work. According to <javac>
> documentation, "srcdir" is a path-like structure and is settable via
> nested <src> elements. This is what I am doing in both cases. Also, per
> documentation path-like structures are allowed to contain nested
<fileset>
> elements, which is what I am doing in option A. Yet it does not work --
> could someone explain why?
>
> It appears to me that I should change my way of thinking: instead of
> <javac> being a target working with 2 filesets (srcdir, classpath, and
> bootclasspath) I am supposed to think of it as a source fileset (srcdir)
> that works with other filesets (classpath and bootclasspath). I don't
> quite see why the latter would be more logical.
>
> Thanks in advance,
> Vlad