Return-Path: 
 <ant-user-return-12218-apmail-jakarta-ant-user-archive=jakarta.apache.org@jakarta.apache.org>
Delivered-To: apmail-jakarta-ant-user-archive@jakarta.apache.org
Received: (qmail 82865 invoked by uid 500); 5 Sep 2001 15:50:59 -0000
Mailing-List: contact ant-user-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
List-Post: <mailto:ant-user@jakarta.apache.org>
List-Help: <mailto:ant-user-help@jakarta.apache.org>
List-Unsubscribe: <mailto:ant-user-unsubscribe@jakarta.apache.org>
List-Subscribe: <mailto:ant-user-subscribe@jakarta.apache.org>
Reply-To: ant-user@jakarta.apache.org
Delivered-To: mailing list ant-user@jakarta.apache.org
Received: (qmail 82853 invoked from network); 5 Sep 2001 15:50:59 -0000
Message-ID: <662DA08450FFD311893500508BC26BADD4E924@wildcat.tilion.com>
From: "Brown, Sheldon" <SBrown@Tilion.com>
To: "'ant-user@jakarta.apache.org'" <ant-user@jakarta.apache.org>
Subject: RE: FTP Task's "mkdir" action
Date: Wed, 5 Sep 2001 11:50:32 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N

>From my understanding of it, this is a limitation of the FTP protocol, not
ANT.  Ever used command line FTP and run into the same problem? (UNIX or
DOS).  The application level needs to have the intelligence to recurse, as
FTP does not support it.  So there is an argument for ANT supporting it, but
it would be a feature.  As it is now I suspect is merely raps the FTP mkdir
command.

Sheldon

-----Original Message-----
From: Matt Lyon [mailto:matt@stargus.com]
Sent: Wednesday, September 05, 2001 11:31 AM
To: Ant User Mailing List (E-mail)
Subject: FTP Task's "mkdir" action


All,

Maybe I am missing something here, so feel free to administer an
intellectual dope-slap if that is the case. I have been tuning up my
buildfiles to take advantage of some of Ant 1.4's new features, and I
was quite chuffed to find that the optional FTP task now supports mkdir.
However, I was subsequently kind of bummed to find that I could not use
the mkdir action to generate recursive (e.g. nested) directory
structures. For example, consider the following build.xml snippet:

		<ftp action="mkdir"
		     server="${publish.sys}"
		     userid="${publish.user}"
		     password="${publish.pass}"
	
remotedir="/export/home/stargus/build/workdir${build.number}/java"/>

In this example, the task fails if the directory structure
/export/home/stargus/build/workdir${build.number} does not already
exist. The obvious workaround is to code two separate tasks as follows:

		<ftp action="mkdir"
		     server="${publish.sys}"
		     userid="${publish.user}"
		     password="${publish.pass}"
	
remotedir="/export/home/stargus/build/workdir${build.number}"/>
		<ftp action="mkdir"
		     server="${publish.sys}"
		     userid="${publish.user}"
		     password="${publish.pass}"
	
remotedir="/export/home/stargus/build/workdir${build.number}/java"/>
		
It would be nice if mkdir could recursively generate the nested
directory structure that I publish builds to on our distribution site,
as it would save a wee bit of typing (OK, not that much in reality). In
any case, I wanted to post this thread as a sanity check. Am I using the
FTP task's "mkdir" action incorrectly, or am I being nit-picky, or both?

Cheers,

Matt