ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Klas Eriksson <>
Subject RE: ant/javac prepends destdir to classpath
Date Mon, 02 Aug 2004 14:20:13 GMT
Thanks for your suggested work-arounds.

Today we check for strange pkg dependencies in a separate 'runTests'
target that uses a solution similar to your different-classes-directories.
My goal was to remove this unnessesary step since I noticed that,
with the correct cmd-line args, javac is able to only compile reusable
Unfortunately I discovered that ant removes this powerful feature
by extending the class-path in an uncontrollable way.
I wounder if there is a reason for this behaviour?


-----Original Message-----
From: Dominique Devienne [] 
Sent: Monday, August 02, 2004 4:06 PM
To: Ant Users List
Subject: RE: ant/javac prepends destdir to classpath

> From: Dominique Devienne []
> Subject: RE: ant/javac prepends destdir to classpath
> > 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
> strange
> > 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,
> if they have dependencies on classes not explicitly on the classpath
> 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
> 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
> 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
> but outputting to a single classes/ dir instead, so it at least
> bad dependencies in a linear fashion. A source group fails to compile
> 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.

I failed to mention here that the bad dependencies are caught on a full
rebuild only, and not during incremental builds. Even if developers
don't rebuild before check ins (and we'd be surprised how often this
happens :-(, at least the continuous integration build always does a
rebuild, so a bad dependency is quickly discovered.

The advantage of the different destdir solution is that dependencies are
enforced correctly even during incremental builds.

> Finally, note that compilation is several passes like this does not
> 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:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message