RE: PROPOSAL: New Java Build Feature

[Denis, Ronald J (Ronald)** CTR **]

Thanks Eric,

This has made things clearer.  A scan of the functional requirements for
Ant2 seems to indicate that better support for dependency lists are being
looked at.

<snip>
:jakarta-ant-1.3\docs\ant2\FunctionalRequirements.html:

Every build process contains dependencies (e.g. item A needs B to be
available before its own build can start). It should be possible to specify
these dependencies in a declarative way.

Suppose a working build specification for system A is available. It should
be possible for system B to declare dependencies to (modules of?) system A
without touching the build specification of A. Ant should be able to handle
dependencies between modules which form a DAG.
</snip>

This dependency issue is the only concern that I have with ant, and in
practice it's a minor issue.  It is far superior to make in terms of speed,
its easy to create build files, the build files are much easier to learn
than cryptic makefiles, and (as you indicated) the build files are portable.

I would encourage others on this list who have not yet tried ant for their
builds to at least take a look.

Ron

> 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
>