Re: is too interpretative - absolute-path-expansion is a severe restriction

[Jacob Kjome <ho...@visi.com>]

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

Re: is too interpretative - absolute-path-expansion is a severe restriction

[Matt Benson <gu...@yahoo.com>]

Patch forthcoming that should allow him to have his
cake and eat it too... see
http://issues.apache.org/bugzilla/show_bug.cgi?id=26364

-Matt

--- Jacob Kjome <ho...@visi.com> wrote:
> 
> 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


__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free web site building tool. Try it!
http://webhosting.yahoo.com/ps/sb/

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