Return-Path: Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm Delivered-To: mailing list ant-dev@jakarta.apache.org Received: (qmail 81575 invoked from network); 27 Jun 2000 21:28:38 -0000 Received: from fep9.mail.ozemail.net (203.2.192.103) by locus.apache.org with SMTP; 27 Jun 2000 21:28:38 -0000 Received: from cognetnt (1Cust214.tnt3.syd2.da.uu.net [63.12.2.214]) by fep9.mail.ozemail.net (8.9.0/8.6.12) with SMTP id HAA25017 for ; Wed, 28 Jun 2000 07:27:50 +1000 (EST) From: "Conor MacNeill" To: Subject: RE: Java / Exec problem... Date: Wed, 28 Jun 2000 07:26:37 +1000 Message-ID: <001001bfe07e$60511190$80dc1fcb@cognet.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N John, I don't know the history behind the choice of the name 'fork' for this attribute but I understand the confusion. Really the use of fork just means that the class is run in a separate VM which is actually invoked in the Exec code. When a task is exec'd the current VM blocks until the task completes (Process.waitFor). It is not really to do with the piping of the output. So, yes, not much of a fork :-( More like "fork and block". If you read the thread on this list about Multithreading, you will see that there is some discussion going on about running tasks in separate threads. I have submitted a patch to make this happen but the final shape of support for this is still being kicked around. Cheers Conor > -----Original Message----- > From: John Zollinger [mailto:john.zollinger@sundog.com] > Sent: Wednesday, 28 June 2000 2:27 > To: Ant-Dev > Subject: Java / Exec problem... > > > Using build 'ant-20000626.zip' on Windows 2000, Sun's JDK 1.3 > > The java task isn't working for me. I needed the task to fork, > but it seems > that exec holds onto any started task now for piping the stderr, stdout > stuff and does not let go until the task finishes, which isn't really much > of a fork. :-) The holding on of the exec'd command and piping the output > should be an option I think, rather than the default. > > Also (probably because it isn't really forking) my application which uses > Runtime.getRuntime().exec() itself is not working any longer. > > Any ideas? > > John Zollinger > V.P. Software Engineering, CTO > Sundog Technologies, Inc. > john.zollinger@sundog.com > > http://www.sundog.com/ > >