I stand corrected - the depend task works exactly as Mark says it does.
Mark, thanks for bringing this to my attention.
Eric
In message <[EMAIL PROTECTED]>, M
ark Bucciarelli writes:
: Actually, Ant does handle the dependency example you present below.
:
: Use the optional <depend> task. The following build.xml will recompile both
: A.java and B.java in your step 4 below.
:
: <project name="tmp" default="all" basedir=".">
: <property name="build" value="./build/" />
: <target name="all" >
: <mkdir dir="${build}" />
: <depend srcdir="${basedir}"
: destdir="${build}"
: cache="depcache"/>
: <javac srcdir="${basedir}"
: depend="on"
: includes="A.java, B.java"
: destdir="${build}"
: classpath=".;${build}"
: debug="on"
: />
: </target>
: </project>
:
: If you're interested in reading the docs, I've included the text from the
: Ant manual for the depend task. Thanks for bringing this to my attention--I
: had indeed missed it.
:
: Depend
: A task to manage Java class file dependencies.
: Description
: The depend task works by determining which classes are out of date with
: respect to their source and then removing the class files of any other
: classes which depend on the out-of-date classes.
:
: To determine the class dependencies, the depend task analyses the class
: files of all class files passed to it. Depend does not parse your source
: code in any way but relies upon the class references encoded into the class
: files by the compiler. This is generally faster than parsing the Java
: source.
:
: To learn more about how this information is obtained from the class files,
: please refer to the Java Virtual Machine Specification
:
: Since a class' dependencies only change when the class itself changes, the
: depend task is able to cache dependency information. Only those class files
: which have changed will have their dependency information re-analysed. Note
: that if you change a class' dependencies by changing the source, it will be
: recompiled anyway. You can examine the dependency files created to
: understand the dependencies of your classes. Please do not rely, however, on
: the format of the information, as it may change in a later release.
:
: Once depend discovers all of the class dependencies, it "inverts" this
: relation to determine, for each class, which other classes are dependent
: upon it. This "affects" list is used to discover which classes are
: invalidated by the out of date class. The class files of the invalidated
: classes are removed, triggering the compilation of the affected classes.
:
: The depend task supports an attribute, "closure" which controls whether
: depend will only consider direct class-class relationships or whether it
: will also consider transitive, indirect relationships. For example, say
: there are three classes, A, which depends on B, which in-turn depend on C.
: Now say that class C is out of date. Without closure, only class B would be
: removed by depend. With closure set, class A would also be removed. Normally
: direct relationships are sufficient - it is unusual for a class to depend on
: another without having a direct relationship. With closure set, you will
: notice that depend typically removes far more class files.
:
: Performance
: The performance of the depend task is dependent on a number of factors such
: as class relationship complexity and how many class files are out of date.
: The following tests have been run when build Ant itself, on the author's
: machine using JDK1.3
:
: Building Ant from clean using Javac 11 seconds
: Building Ant from clean using Jikes 5 seconds
: Running <depend> when up-to-date and no cache 4 seconds (Depend takes 2
: seconds)
: Running <depend> when up-to-date and with a cache 2 seconds (Depend takes 1
: seconds)
:
: This involves compiling 177 files. The above figures are indicative only.
: The decision about whether it is cheaper to just recompile all classes or to
: use the depend task will depend on the size of your project and how
: interrelated your classes are.
:
: Limitations
: There are some dependencies which depend will not detect.
:
: If the Java compiler optimizes away a class relationship, there can be a
: source dependency without a class dependency.
: Non public classes cause two problems. Firstly depend cannot relate the
: class file to a source file. In the future this may be addressed using the
: source file attribute in the classfile. Secondly, neither depend nor the
: compiler tasks can detect when a non public class is missing. Inner classes
: are handled by the depend task.
: Parameters
: Attribute Description Required
: srcDir This is the directory where the source exists. depend will examine
: this to determine which classes. If you use multiple source directories you
: can pass this a path of source directories. Yes
: destDir This is the root directory of the class files which will be
: analysed. If this is not present, the srcdir is used. No
: cache This is a directory in which depend can store and retrieve dependency
: information. If this is not present, depend will not use a cache No
: closure This attribute controls whether depend only removes classes which
: directly depend on out of date classes. If this is set to true, depend will
: traverse the class dependency graph deleting all affected classes. Defaults
: to false No
:
: Examples
: <depend srcdir="${java.dir}"
: destdir="${build.classes}"
: cache="depcache"
: closure="yes"/>
: In this example classes in the ${build.classes} directory will be removed if
: they depend on out-of-date classes. Classes are considered out of date with
: respect to the source in the ${java.dir} directory using the same mechanism
: as the javac task. In this instance the depend task caches its dependency
: information in the depcache directory.
:
:
: ----------------------------------------------------------------------------
: ----
:
: Copyright © 2000,2001 Apache Software Foundation. All rights Reserved.
:
: > -----Original Message-----
: > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
: > Sent: Tuesday, March 20, 2001 11:38 PM
: > To: Denis, Ronald J (Ronald)** CTR **
: > Cc: JDE Mailing List
: > Subject: Re: PROPOSAL: New Java Build Feature
: >
: >
: >
: > 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
: >
:
