In message <[EMAIL PROTECTED]
m>, "Denis, Ronald J (Ronald)** CTR **" writes:
: I too use ant for my builds. It does not compile
: every file every time. However, admittedly there have
: been times when compile errors occur which only go away
: upon a full rebuild. This doesn't happen often but does
: happen often enough that its annoying.
It's quite clear why and when this happens. Ant does an "up to date"
check on the source files you hand to its "javac" task (which could also
be handled by jikes) and passes the compiler a list of .java files that
are older than their corresponding .class files. This is why Ant will
always rebuild classes that are not organized in a directory structure
that mirrors the package hierarchy.
It's also why Ant cannot handle the following case unless you do a full,
clean build:
1. write the following classes
class A {
void foo() { }
}
class B extends A {
void bar() { foo(); }
}
2. build and run: everything is fine.
3. now change A as follows:
class A {
void foo(int i) { }
}
4. build with Ant and only A gets rebuilt (as it is the only out-of-date
source file)
5. run and you will get a java.lang.NoSuchMethodError
Conclusions:
Ant is not the panacea that some, charmingly (alarmingly?) naive users
claim that it is. It has a couple of advantages over make:
1. it does not fire up multiple VMs to do a build;
2. it is hard to write non-portable build files (with make the inverse is true);
3. it does not require much from users - no shell, sed, awk wizardry required;
With that said, Ant does not offer any fundamental advantage over make in
terms of dependency analysis. Using timestamps to recompile class files
is simply not enough in java, as the example above makes clear.
Eric
