Here are the options

[Matt Seibert <ms...@us.ibm.com>]

As far as I can tell, ANT has no concept of "true dependancies" (i.e. it
doesn't know if something has already been done).

So, with a nice tight set of targets like these in the axis build.xml file:

<compile depends="setenv"/>
<buildTest depends="compile"/>
<junit depends="buildTest"/>
<all-tests depends="junit, functional-tests"/>

If you exec "ant all-tests", you exec compile 4 times and exec buildTest 3
times (which is my big leaky target right now), instead of what you would
EXPECT to see which is:
compile
      ->buildTest
            ->junit
then exec functional-tests

So, we have to either make ANT smarter, or our process dumber.  Here is
what I've got so far:
ant clean compile buildTest   (java consumes 284 M of ram when you're done)
                        buildTest does a "samples" build when it builds
test/functional (as a pre-req)
ant all-tests                 (java consumes < 100 M of ram when you're
done)
                        This execs ONLY junit and functional-tests.  No
compilations.....

running this as two process commands "stops" ant between calls, and frees
the memory that it is leaking.

As far as I can see, here are my options for fixing what is broken, in my
order of preference.
      1) Change the "documented build process" to be "Compile, THEN test",
instead of the ability to "ant all-tests" as today
            This means "ant clean compile buildTest; ant all-tests"
      2) Beat the crap out of the Ant guys until they give us a "forking"
Ant Task.....
      3) "Externally EXEC" the ant calls in the buildTest target (since
there is no "forking" in Ant)
            I, personally, DO NOT LIKE THIS IDEA
      4) Re-instate the buildTest and samples targets from the old
build.xml, and leave the build.xml files in the component Trees
            which means things get out of sync REALLY fast and REALLY
easily.

Matt Seibert                                           mseibert@us.ibm.com
IBM        External:    (512) 838-3656      Internal:   678-3656

Re: Here are the options

[Steve Loughran <st...@iseran.com>]

----- Original Message -----
From: "Matt Seibert" <ms...@us.ibm.com>

> So, we have to either make ANT smarter, or our process dumber.  Here is
> what I've got so far:
> ant clean compile buildTest   (java consumes 284 M of ram when you're
done)
>                         buildTest does a "samples" build when it builds
> test/functional (as a pre-req)
> ant all-tests                 (java consumes < 100 M of ram when you're
> done)
>                         This execs ONLY junit and functional-tests.  No
> compilations.....
>
> running this as two process commands "stops" ant between calls, and frees
> the memory that it is leaking.

I have a fix for ant that I'm just testing; if it looks on on ant and axis
tests then I'll commit it before the gump runs; it uses weak references to
stop tasks being cached. Of course, it assumes that I have identified the
cause of the leakage correctly...

Re: Here are the options

[Steve Loughran <st...@iseran.com>]

I just posted to this list and ant-dev what the probable cause is, that
ant1.5+ caches all tasks created in a hashmap by type. This may seem
spurious but it addresses a problem of people redefining task definitions
and follow on bad things.

A quick hack to have a new createTask call without doing the cache was easy,
but isnt the real solution, and ties <foreach> and hence axis builds to
CVS-HEAD versions of ant, which is too bleeding edge.

Ant should move to using weak references in the cache. I'll see what I can
do over lunch, if this works we can feed it back into the ant1.5.1 branch,
as it wont change the external appearance of ant any.


----- Original Message -----
From: "Matt Seibert" <ms...@us.ibm.com>
To: <ax...@xml.apache.org>
Sent: Tuesday, September 10, 2002 10:38 AM
Subject: Here are the options



>
> As far as I can see, here are my options for fixing what is broken, in my
> order of preference.
>       1) Change the "documented build process" to be "Compile, THEN test",
> instead of the ability to "ant all-tests" as today
>             This means "ant clean compile buildTest; ant all-tests"
>       2) Beat the crap out of the Ant guys until they give us a "forking"
> Ant Task.....
>       3) "Externally EXEC" the ant calls in the buildTest target (since
> there is no "forking" in Ant)
>             I, personally, DO NOT LIKE THIS IDEA
>       4) Re-instate the buildTest and samples targets from the old
> build.xml, and leave the build.xml files in the component Trees
>             which means things get out of sync REALLY fast and REALLY
> easily.