ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Morten S. Mortensen" <>
Subject <pathconvert> is too interpretative - absolute-path-expansion is a severe restriction
Date Sun, 25 Jan 2004 14:52:01 GMT
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?
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"/>

Using <pathconvert> like -

- I get the output -
     [echo] "C:/test2/${env.J2EE_HOME}/lib/j2ee.jar:C:/test2/lib/theArchiveBuilt
Now, WHY does it make all my paths ABSOLUTE?? Not what I want.
Trying to put <map> element in there -
      <map from="${basedir}" to=""/>

- I get the output -
     [echo] "/${env.J2EE_HOME}/lib/j2ee.jar:/lib/theArchiveBuiltByThisProject.j
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" -
      <map from="${basedir}\" to=""/>

- I *can* get rid of the leading '\' -
     [echo] "${env.J2EE_HOME}\lib\j2ee.jar;lib\theArchiveBuiltByThisProject.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. 
Morten Sabroe Mortensen
View raw message