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

["Morten S. Mortensen" <mo...@tietoenator.com>]

 
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