| <pathconvert > is too interpretative - absolute-path-expansion is a severe restri | <pathconvert > is too interpretative - absolute-path-expansion is a severe restri 2004-01-25 - By Morten S. Mortensen
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
|
|
 |
