ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Morten S. Mortensen" <morten.morten...@tietoenator.com>
Subject RE: <pathconvert> is too interpretative - absolute-path-expansion is a severe restriction
Date Fri, 30 Jan 2004 10:43:30 GMT

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


Mime
View raw message