Return-Path: 
 <ant-user-return-26656-qmlist-jakarta-archive-ant-user=jakarta.apache.org@jakarta.apache.org>
Delivered-To: apmail-jakarta-ant-user-archive@apache.org
Received: (qmail 87044 invoked from network); 8 Nov 2002 15:04:27 -0000
Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131)
  by daedalus.apache.org with SMTP; 8 Nov 2002 15:04:27 -0000
Received: (qmail 7700 invoked by uid 97); 8 Nov 2002 15:05:11 -0000
Delivered-To: qmlist-jakarta-archive-ant-user@jakarta.apache.org
Received: (qmail 7684 invoked by uid 97); 8 Nov 2002 15:05:11 -0000
Mailing-List: contact ant-user-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:ant-user-unsubscribe@jakarta.apache.org>
List-Subscribe: <mailto:ant-user-subscribe@jakarta.apache.org>
List-Help: <mailto:ant-user-help@jakarta.apache.org>
List-Post: <mailto:ant-user@jakarta.apache.org>
List-Id: "Ant Users List" <ant-user.jakarta.apache.org>
Reply-To: "Ant Users List" <ant-user@jakarta.apache.org>
Delivered-To: mailing list ant-user@jakarta.apache.org
Received: (qmail 7672 invoked by uid 98); 8 Nov 2002 15:05:10 -0000
X-Antivirus: nagoya (v4218 created Aug 14 2002)
Message-ID: <3DCBD1FF.5070204@ertonline.gr>
Date: Fri, 08 Nov 2002 17:02:23 +0200
X-Sybari-Trust: 7f88d094 941f1c9f 5fd1788e 0000093d
From: Anakreon Mejdi <amejdi@ertonline.gr>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: el, en-us
MIME-Version: 1.0
To: Ant Users List <ant-user@jakarta.apache.org>
Subject: Re: Apply/Exec
References: <3DCBC653.7080507@ertonline.gr>
 <m38z04cfh6.fsf@bodewig.bost.de>	<3DCBCB2D.6070305@ertonline.gr>
 <m34rasce9i.fsf@bodewig.bost.de>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N



Stefan Bodewig wrote:
> On Fri, 08 Nov 2002, Anakreon Mejdi <amejdi@ertonline.gr> wrote:
> 
> 
>>I think it could handle it.  apply knows in which OS is running and
>>from a configuration (stored in ant.jar) could know how many
>>parameters the OS can receive.
> 
> 
> Not really.  It is the total lenght, not the number of arguments that
> is often the limit.
Params are String so length could be calculated in that case.

> 
> 
>>For example lets say that an OS can take 10 params and 3 are passed
>>as <arg> from the apply taks.  So we have 7 params which can use.
>>>From the fileset we have 100 files.  What apply could do is to split
>>the 100 files into portions of 7 and for each 7 params execute the
>>process.
> 
> 
> But this doesn't work for all cases.  Sometimes parallel="true" cannot
> be split into sevaral invocations without causing problems.
> 
> Take tar as executable.  "tar cf archive.tar file1 .... fileN" creates
> archive.tar from the files.  I can not simply split this into several
> commands as I'd have to use "tar rf archive.tar ...." in the second
> and subsequent calls to append instead of overwrite the existing
> archive.
Yes, this is true.
But if parallel was false wouldn't this mean  that the commands would be:
tar cf archive.tar file1
tar cf archive.tar file2
.....
tar cf archive.tar fileN
In this case what would be the result?
An archive which would contain only fileN?
If the answer is yes (I am not familiar with tar to know the answer)
apply would not be the correct task any way.
Most likely tar must have a parameter to append contents into existing 
archive.
tar is just an example, but what I mean is that if by splitting the 
parameters it wouldn't work, if parallel is false it won't work either.
I might be wrong , so I don't insist any longer.

Thanks for  answering.
Anakreon


--
To unsubscribe, e-mail:   <mailto:ant-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-user-help@jakarta.apache.org>