Return-Path: 
 <user-return-40659-apmail-ant-user-archive=ant.apache.org@ant.apache.org>
Delivered-To: apmail-ant-user-archive@www.apache.org
Received: (qmail 58293 invoked from network); 30 Jan 2004 13:59:15 -0000
Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12)
  by minotaur-2.apache.org with SMTP; 30 Jan 2004 13:59:15 -0000
Received: (qmail 7042 invoked by uid 500); 30 Jan 2004 13:58:35 -0000
Delivered-To: apmail-ant-user-archive@ant.apache.org
Received: (qmail 6983 invoked by uid 500); 30 Jan 2004 13:58:35 -0000
Mailing-List: contact user-help@ant.apache.org; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:user-unsubscribe@ant.apache.org>
List-Subscribe: <mailto:user-subscribe@ant.apache.org>
List-Help: <mailto:user-help@ant.apache.org>
List-Post: <mailto:user@ant.apache.org>
List-Id: "Ant Users List" <user.ant.apache.org>
Reply-To: "Ant Users List" <user@ant.apache.org>
Delivered-To: mailing list user@ant.apache.org
Received: (qmail 6918 invoked from network); 30 Jan 2004 13:58:34 -0000
Received: from unknown (HELO mail-out.visi.com) (209.98.98.22)
  by daedalus.apache.org with SMTP; 30 Jan 2004 13:58:34 -0000
Received: from mehen.visi.com (mehen.visi.com [209.98.98.97])
	by mail-out.visi.com (Postfix) with ESMTP id 9178B36CB
	for <user@ant.apache.org>; Fri, 30 Jan 2004 08:00:13 -0600 (CST)
Received: from mehen.visi.com (localhost [127.0.0.1])
	by mehen.visi.com (8.12.9/8.12.5) with ESMTP id i0UDwUVQ087442
	for <user@ant.apache.org>; Fri, 30 Jan 2004 07:58:30 -0600 (CST)
	(envelope-from hoju@visi.com)
Received: (from www@localhost)
	by mehen.visi.com (8.12.9/8.12.5/Submit) id i0UDwU6f087441
	for user@ant.apache.org; Fri, 30 Jan 2004 13:58:30 GMT
X-Authentication-Warning: mehen.visi.com: www set sender to hoju@visi.com
 using -f
Received: from linterlock.hartfordlife.com (linterlock.hartfordlife.com
 [199.222.100.4])
	by my.visi.com (IMP) with HTTP
	for <hoju@baal.visi.com>; Fri, 30 Jan 2004 13:58:30 +0000
Message-ID: <1075471110.401a6306b2da5@my.visi.com>
Date: Fri, 30 Jan 2004 13:58:30 +0000
From: Jacob Kjome <hoju@visi.com>
To: Ant Users List <user@ant.apache.org>
Subject: RE: <pathconvert> is too interpretative -  absolute-path-expansion is
 a severe restriction
References: <2CC763883B72EB43BF36B484F01B304B146CDB@balder.tefs.corpdk.inside>
In-Reply-To: 
 <2CC763883B72EB43BF36B484F01B304B146CDB@balder.tefs.corpdk.inside>
MIME-Version: 1.0
Content-Type: text/plain
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
User-Agent: Internet Messaging Program (IMP) 4.0-cvs
X-Originating-IP: 199.222.100.4
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N
X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N

Quoting "Morten S. Mortensen" <morten.mortensen@tietoenator.com>:

> 
> Jake, you actually meant <pathelement value="..."/>, right?
> 
> Hmmm... Apparently, no such attribute exists -
> 
> 
> C:\work\......\xxx.xml:19: Class org.apache.tools.ant.types.Path$PathElement
> doesn't support the "value" attribute.
> 
> Total time: 1 second
> C:\work\......>ant -version
> Apache Ant version 1.6.0 compiled on December 18 2003

Ug, you're right.  When I posted the message I was thinking about the location
-vs- value attributes of the <property> element.  Sorry for spreading confusion.
 Please disregard what I said.

Jake

> 
> 
> Regards,
> Morten Sabroe Mortensen
> 
> 
> -----Original Message-----
> From: Jacob Kjome [mailto:hoju@visi.com]
> Sent: 25. januar 2004 16:38
> To: Ant Users List
> Subject: Re: <pathconvert> is too interpretative -
> absolute-path-expansion is a severe restriction
> 
> 
> 
> If you didn't want your paths expanded, why did you use the "location"
> attribute in your <pathelement>'s???  If you use "value", then the paths
> won't be expanded.  The path expansion is happening before
> <pathconvert>.  This is user error from what I can tell.
> 
> Jake
> 
> At 03:52 PM 1/25/2004 +0100, you wrote:
> >
> >I have high hopes for the <pathconvert> task, since I use traditional
> >string-like paths as input for a lot of tools and I want the original path
> >to have a bit more flexibility.
> >
> >But I am somewhat disappointed with the <pathconvert> task; it kind of
> >makes its own interpretation about what the path should be used for, I
> >think. The expansion into all absolute paths is severe.
> >
> >Perhaps some one have more experience with this and some hints?
> >
> >      -----
> >
> >Example:
> >
> >For my first set of experiments I specify a path like:
> >
> >   <!-- Path to locate the classpath used at run-time: -->
> >   <path id="runtime.class.path">
> >     <pathelement location="${env.J2EE_HOME}/lib/j2ee.jar"/>
> >     <pathelement location="lib/theArchiveBuiltByThisProject.jar"/>
> >     <pathelement location="lib/external1.jar"/>
> >     <pathelement location="lib/external2.jar"/>
> >     <pathelement location="lib/external3.jar"/>
> >   </path>
> >
> >Using <pathconvert> like -
> >
> >     <pathconvert
> >       property="runtime.class.path.string"
> >       refid="runtime.class.path"
> >       setonempty="false"
> >       targetos="unix"
> >     >
> >     </pathconvert>
> >     <echo>"${runtime.class.path.string}"</echo>
> >
> >- I get the output -
> >
> >      [echo]
> > "C:/test2/${env.J2EE_HOME}/lib/j2ee.jar:C:/test2/lib/theArchiveBuilt
> >ByThisProject.jar:C:/test2/lib/external1.jar:C:/test2/lib/external2.jar:C:/test2
> >/lib/external3.jar"
> >
> >Now, WHY does it make all my paths ABSOLUTE?? Not what I want.
> >
> >Trying to put <map> element in there -
> >
> >     <pathconvert
> >       property="runtime.class.path.string"
> >       refid="runtime.class.path"
> >       setonempty="false"
> >       targetos="unix"
> >     >
> >       <map from="${basedir}" to=""/>
> >     </pathconvert>
> >     <echo>"${runtime.class.path.string}"</echo>
> >
> >- I get the output -
> >
> >      [echo]
> > "/${env.J2EE_HOME}/lib/j2ee.jar:/lib/theArchiveBuiltByThisProject.j
> >r:/lib/external1.jar:/lib/external2.jar:/lib/external3.jar"
> >
> >Hmm. Now it insist upon leading '/'. Not what I want. -And not what I
> >wrote in the <path>-element with either a leading '/' or a leading '\'.
> >Changing the map to containing a trailing '/' '<map from="${basedir}/"
> >to=""/>' does not change the output. I wonder why. This is *somewhat*
> >reasonable, since UNIX-dir-names usually are specified with a leading '/'.
> >But it is still interpretative; how does it know that my context of use
> >does not require and explicit '.' like in "./"??
> >
> >If I change the "targetos"-attribute to "windows" -
> >
> >     <pathconvert
> >       property="runtime.class.path.string"
> >       refid="runtime.class.path"
> >       setonempty="false"
> >       targetos="windows"
> >     >
> >       <map from="${basedir}\" to=""/>
> >     </pathconvert>
> >     <echo>"${runtime.class.path.string}"</echo>
> >
> >- I *can* get rid of the leading '\' -
> >
> >      [echo]
> > "${env.J2EE_HOME}\lib\j2ee.jar;lib\theArchiveBuiltByThisProject.jar;
> >lib\external1.jar;lib\external2.jar;lib\external3.jar"
> >
> >- and this pleases me, since this is what I wrote in the path-element!
> >Except that file-separators are not the Java-native '/', which I need.
> >
> >For some purposes, I would like to specify a prefix like "misc/etc".
> >
> >In conclusion, it would be REALLY NICE if -
> >
> >1) Local paths were kept local and were not expanded into something
> absolute.
> >    Then scenarios like "generate a file on one system, let the complete,
> > relative structure be copied to another system and run it there!" - which
> > is not possible with absolute paths, if it is between Windows and UNIX or
> > just two separate offsets on instanses of the same type of system!!
> >    How about an attribute 'keepLocalPaths="true"' to <pathconvert> (with
> > a default-value of "false")??
> >2) No leading file-separators were added to directories.
> >    Handling class-path separators ':' and ';' is great, handling
> > file-separators '/', '\' and whatever is great, but adding separators to
> > the front a directories is not great.
> >
> >I may be missing something, but I will argue in favor of just a bit more
> >control (less interpretation) over the result from <pathconvert>/<path>.
> >The expansion into absolute paths is a severe restriction upon possible
> uses.
> >
> >Regards,
> >Morten Sabroe Mortensen
> >
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
> For additional commands, e-mail: user-help@ant.apache.org
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
> For additional commands, e-mail: user-help@ant.apache.org

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