On 10/18/06, Dominique Devienne <[EMAIL PROTECTED]> wrote:
> Timing indicates that ant is spending 30 seconds per test to walk the
lib
> tree building the classpath. Does anyone have a solution to this
problem?
Frankly, that sounds a bit fishy ;-)
Unless your hierarchy is
exceedingly large in ${lib.dir}, it's unlikely it's the fileset scan
that's taking so long. I'd write a build file that only defines the
<fileset>, then <pathconvert>s it and <echo>s it, with timestamps
around to find out for sure how long is the scan.
Thanks for the suggestion. I did that, and it really does take that long.
The JARs are stored remotely in a Clearcase VOB, so that slows things down a
bit. Still, I don't understand why the fileset scan takes 30 seconds, while
the native find command does the same thing in under 2 seconds.
I'm pretty new to Java development. Is Java really that much slower than
native code? We're currently using the 1.4.2 SDK. Will it be any faster
when we migrate to 1.5?
Could be that you have fork="true" on JUnit, and the overhead of
starting a new VM and/or the test infrastructure is to blame???
That's definitely not it.
Is the scan really is that slow, then you could expand once all
jars/zips in a single dir, and use that dir on the classpath (and/or
create an uber-jar of this dir).
We're using a number of libraries that are currently under development, so
we couldn't do this just once and forget about it. I think I'm going to try
to change org.apache.tools.ant.types.AbstractFileSet so that it only scans
once, instead of scanning every time it is used. If that works I'll post it
to the Ant development list.
a LOT of JARs is too vague I guess. Do the self-contained timing test
above, and give us some more indication as to what LOT means in this
case. --DD
A lot = 102.
