ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Reilly <peter.rei...@corvil.com>
Subject Re: <pathconvert> is too interpretative - absolute-path-expansion is a severe restriction
Date Fri, 30 Jan 2004 11:31:37 GMT
The problem is the <path> type. This does not
have the concept of a base directory - like <fileset>.
and stores all file names as absolute filenamepaths.

There is one call: Path#list() which returns an array of these.
This is then used by the <pathconvert/> task.

Peter
Morten S. Mortensen wrote:

>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
>
>
>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


Mime
View raw message