ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dominique Devienne" <>
Subject RE: ant/javac prepends destdir to classpath
Date Mon, 02 Aug 2004 13:59:56 GMT
> From: Klas Eriksson []
> To rewrite the rule like
>      <javac srcdir="SRC"
>             destdir="classes"
>             includeAntRuntime="no"
>             classpath="3rdpartyjars/castor-xml.jar">
>        <include name="se/micronic/util1/**"/>
>      </javac>
>      <javac srcdir="SRC"
>             destdir="classes"
>             includeAntRuntime="no"
>             classpath="3rdpartyjars/castor-xml.jar">
>        <include name="/se/micronic/util2/**"/>
                        ^ no slash
>      </javac>
> is a bad idea. Javac is greedy and will automatically accept any
> dependencies to other code.

You can tell Javac not to be 'greedy' as you put it by adding
sourcepath="" to <javac>. You will compile just the files included, and
if they have dependencies on classes not explicitly on the classpath (or
in classes...), then the compile will fail (I use this trick
extensively, as does the <compilewithwalls> Ant-Contrib task.

But as you've discovered, classes already in Javac's destdir will be
used by the compiler, so even with sourcepath="", a dependency on the
first compiled set of sources could creep up in the second set of
sources. If you really want to enforce the stand-alone'ness of both set
of sources, you need to use a different destdir, once for each set.
Other sources compiled later on simply have to add these different
destdirs on their classpath if they depend on the utility classes.

I went even farther, breaking down a large code base into many such self
contained source groups, with clean dependency between each, automatic
check of the dependency graph triggering compilation of the various
groups in the right order, etc... and it all rests on sourcepath=""
shoulders. The one big drawback is to now have 15 classes directories.
(IDE users don't like that!)

To avoid this, another project chose to still compile in several passes,
but outputting to a single classes/ dir instead, so it at least catches
bad dependencies in a linear fashion. A source group fails to compile if
it depends on sources from a group compiled later on. In other words,
you check that each layer depends on only stuff compiled in earlier
passes, which is better than nothing.

Finally, note that compilation is several passes like this does not seem
to be any slower than compiling everything in a single pass, at least
for non-trivial compiles and informal testing. --DD

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message