Couple of mods to

[Diane Holt <ho...@yahoo.com>]

I've made a couple of modifications to <javac> for my own needs, but I
thought they might be of use to other users as well.

One problem I was having with <javac> is that I have source files that
live in subdirs, but that need to be built into the top level of the build
tree. The problem was they were always getting rebuilt, since <javac>
makes the class filename match the path of the source filename, and looks
for destdir/srcpath/to/file.class rather than just destdir/file.class --
which is perfectly fine in most cases, just not in all.

So, I pilfered the "flatten" stuff from <copydir> and added it to <javac>.
Now you can have a flatten attribute for <javac>, which when true, will
have it look for the classfile in the destdir you've specified, not in the
destdir modified with the source file's path.

The thing is, I don't know Java any better than I do sanskrit (ie., not at
all :), so I have no idea if the way I did it is actually correct. It
works, but it does seem like I had to do some odd contortions (for one
thing, I cannot get an "else" to work for me in Java -- I have no idea
why). I'm willing to put the change out here, if people are interested in
it -- but only if you promise not to point and laugh.

The second modification I made is along the lines of the one Conor made,
in that it lists the files it's dealing with, but this one lists all the
files it's checking, not just the ones it's going to compile (it just
lists them, it doesn't say anything about their state). I need this,
because I'm dealing with a source tree I can't just say **/*.java with
(there are .java files in it that don't get compiled, and that aren't
going away any time soon). So I want to (not often, but sometimes) see all
the files it's actually picking up so I can compare it against the files I
know it should only be... wildcards make me a little jumpy :)  This one is
turned on with a "listfiles" attribute.  Same qualifiers and offer as
above.

The third thing I tried for, but failed to accomplish in any clean way,
was to have some kind of visual output on really long scans. I can get it
to put a trailing "." across the screen as it goes thru the directories,
which is fine (at least there's enuf going on to not make you think it's
wedged :) -- I just couldn't get it to do it in any kind of reasonable
conditional way, so I had to scrap it for now. If anyone has any ideas on
how I could make it happen tho, I'd be grateful (watching a screen doing
nothing for 7 minutes can be very disheartening... still, it's better than
the 11 I used to have to watch it for :)

(P.S. I also cleaned up all the comments wrt copying files, since as I
understand it that behaviour is gone now.)

Diane

=====
(holtdl@yahoo.com)



__________________________________________________
Do You Yahoo!?
Yahoo! Mail - Free email you can access from anywhere!
http://mail.yahoo.com/

RE: Couple of mods to

[Conor MacNeill <co...@m64.com>]

Diane,

I'm -1 on your patch and I hope I can explain why. The assumption that the
source tree is structured according to the package structure is not unique
to ant but is also used by the Sun javac compiler and, I presume, all other
Java compilers. When a class depends on another class, for which no class
file exists, Javac can automatically compiler a source file to produce a
class file to satisfy the dependency. It can only do so however, if the
classes and source exist in a directory structure which matches the package
structure.

I have attached an example consisting of two classes in two packages, one of
which is dependent on the other.

If you try to compile just the class B.java you get the following

F:\example>javac y\B.java
y\B.java:3: cannot resolve symbol
symbol  : class A
location: package x
import x.A;
         ^
y\B.java:6: cannot resolve symbol
symbol  : class A
location: class y.B
    private A a;
            ^
2 errors

Javac cannot satify the class dependencies. If you now try

F:\example>javac -sourcepath . y\B.java

You will find that it compiles and that javac has automatically built
x/A.class from x/A.java without you even asking it to do that. It only could
do that because the source files directory structure matches the package
structure.

So, there are certain benefits to arranging your source in this way. I think
a lot of people don't do this and end up with a flat set of Java source
files or files organized according in some other way. In most cases that
will still work, especially if you compile everyting the way ant will. For
example, the following compiles fine

F:\example>javac y\B.java x\A.java

I think the current ant behaviour encourages you to use this layout and,
IMHO, that is a good thing. To allow it to support a flat or unrelated
directory structure would not be a good thing.

> One problem I was having with <javac> is that I have source files that
> live in subdirs, but that need to be built into the top level of the build
> tree.

I have to wonder why that is. At work, we have a number of source trees,
which are subdirectories of a "src" directory. These trees are each
organized along package structure lines and are built with independent
<javac> tasks.

> The problem was they were always getting rebuilt, since <javac>
> makes the class filename match the path of the source filename, and looks
> for destdir/srcpath/to/file.class rather than just destdir/file.class --
> which is perfectly fine in most cases, just not in all.

I feel it should be perfectly fine in all cases. Of course, that is easy to
say without knowing the details of your situation.

For further info on javac's behaviour, have a read of
http://java.sun.com/products/jdk/1.2/docs/tooldocs/win32/javac.html

under the section "SEARCHING FOR TYPES"

Cheers
Conor