Bug 8895 - ant and/or antcall should support forking
Summary: ant and/or antcall should support forking
Status: NEW
Alias: None
Product: Ant
Classification: Unclassified
Component: Core tasks (show other bugs)
Version: 1.4.1
Hardware: Other other
: P3 enhancement with 1 vote (vote)
Target Milestone: ---
Assignee: Ant Notifications List
Depends on:
Blocks: 4066
  Show dependency tree
Reported: 2002-05-08 02:14 UTC by Brian Slesinsky
Modified: 2008-11-24 03:57 UTC (History)
1 user (show)


Note You need to log in before you can comment on or make changes to this bug.
Description Brian Slesinsky 2002-05-08 02:14:24 UTC
It would be useful if either ant or antcall (or both) supported a fork parameter
and a classpath element.  This would allow ant to restart itself with a
different classpath.

In particular, I'd like to restart ant with a different classpath to run junit
tests.  Setting fork=true in the junit task causes a new VM to be created for
each test, when I'd rather restart the VM once and run all of the unit tests in
the same VM.

A workaround is to use a TestSuite, but then the test suite can't be interrupted
in the middle, and you don't get the same summary lines.  Also, perhaps the java
task could be used to restart ant, but that's less than obvious.
Comment 1 Peter Donald 2002-05-08 09:47:42 UTC
Fantastic idea. 
Unfortunately we have just recently added the ability which allowed references to be inherited by sub-ants. So we 
would need to make sure inheritRefs=false before allowing ant to be forked. 
Feel free to send a patch to enable this funcitonality. 
Comment 2 Thomas Quas 2003-05-18 10:42:08 UTC
I'd like to see this, too. I have a bunch of homegrown tasks that access a
database which error out if not forked. Hmm, couldn't figure out why.

An <antcall> supporting fork would be great!
Comment 3 Jesse Glick 2005-05-27 02:29:44 UTC
In most (all?) cases where I thought I needed this for scripts I work on, I
found some other way around it. But it could make some things easier.

Forking a new VM might not be necessary for some uses. E.g. sometimes you want
to invoke a child Ant script *without* user-set (-D...) properties.
inherit*="false" does not help here; you just cannot get rid of them.

Should the child script inherit the parent's listeners and loggers?

Probably should be deferred until a more concrete set of use cases is collected,
with reasons why you cannot solve the problem in a straightforward way without
the enhancement.
Comment 4 Trejkaz (pen name) 2008-06-24 16:27:51 UTC
One use case: setting a different memory for a sub-build without requiring setting of ANT_OPTS from the outside.