Return-Path: <rubys@us.ibm.com>
Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm
Delivered-To: mailing list ant-dev@jakarta.apache.org
Received: (qmail 9198 invoked from network); 20 Apr 2000 23:59:43 -0000
Received: from e24.nc.us.ibm.com (32.97.136.230)
  by locus.apache.org with SMTP; 20 Apr 2000 23:59:43 -0000
Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com
 [9.37.3.209])
	by e24.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id TAA17250
	for <ant-dev@jakarta.apache.org>; Thu, 20 Apr 2000 19:47:28 -0500
From: rubys@us.ibm.com
Received: from d54mta04.raleigh.ibm.com (d54mta04.raleigh.ibm.com
 [9.67.228.36])
	by southrelay02.raleigh.ibm.com (8.8.8m3/NCO v2.07) with SMTP id TAA50146
	for <ant-dev@jakarta.apache.org>; Thu, 20 Apr 2000 19:59:40 -0400
Received: by d54mta04.raleigh.ibm.com(Lotus SMTP MTA v4.6.5  (863.2
 5-20-1999))  id 852568C7.0083CB7E ; Thu, 20 Apr 2000 19:59:33 -0400
X-Lotus-FromDomain: IBMUS
To: ant-dev@jakarta.apache.org
Message-ID: <852568C7.0083CB4C.00@d54mta04.raleigh.ibm.com>
Date: Thu, 20 Apr 2000 19:58:57 -0400
Subject: Re: Path & dir separators (was Re: Ant Principles)
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N



Thomas Haas wrote:
> Actually it is not that bad, as createScrdir can return the object
> implementing the "element" element of path. The example will become:
> <copydir>
>    <srcdir url="ftp://repository.example.org/library/foo-files/"/>
>    <destdir file="../lib"/>
> </copydir>
>
> Which for sure is longer than  <copydir srcdir="../foo/"
destdir="../bar/"/>
> but still acceptable, if we go the purist way.
> HOWEVER I have lost track of the creatXXX, setYYY and addZZZ discussion
and
> do not know if the example above is possible. Anyone?

Yes.  The proposals don't change what XML can be supported, but how.  We
evolved our way into the current support, and James is looking into going
back and cleaning it up.

I was waiting until he poked his head back into this mailing list, but he's
probably doesn't have access to e-mail at the moment (he's traveling).

My two cents: we can certainly continue to support the current syntax to
handle the common cases.

In cases where more complex parameters are required (os specific options
and the like), then we should consider separate elements that are parellel
to tasks instead of embedded inside the task.  I reason that paths are
often referenced in multiple places in a build.xml, so this can reduce the
overall size.  In case this is not clear, an abbreviated example
(attributes not relevant to the example are omitted):

<project>
  <target name="main">
    <directory id="work" path="../build"/>
    <javac destdirId="work"/>
    <jar basedirId="work"/>
  </target>
</project>

- Sam Ruby