ant-user mailing list archives

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

> 
> 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

Ug, you're right.  When I posted the message I was thinking about the location
-vs- value attributes of the <property> element.  Sorry for spreading confusion.
 Please disregard what I said.

Jake

> 
> 
> 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

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


Mime
View raw message