Summary: | ant and/or antcall should support forking | ||
---|---|---|---|
Product: | Ant | Reporter: | Brian Slesinsky <bslesins> |
Component: | Core tasks | Assignee: | Ant Notifications List <notifications> |
Status: | NEW --- | ||
Severity: | enhancement | CC: | jglick |
Priority: | P3 | ||
Version: | 1.4.1 | ||
Target Milestone: | --- | ||
Hardware: | Other | ||
OS: | other | ||
Bug Depends on: | |||
Bug Blocks: | 4066 |
Description
Brian Slesinsky
2002-05-08 02:14:24 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. 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! 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. One use case: setting a different memory for a sub-build without requiring setting of ANT_OPTS from the outside. |