ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jose Alberto Fernandez <JFernan...@viquity.com>
Subject RE: [RFC] Suggestion for resolvepath task
Date Fri, 06 Oct 2000 18:35:15 GMT
> From: Matthew Kuperus Heun [mailto:matthew.k.heun@gaerospace.com]
> 
> 1)  Is there a way to do what I want with ANT as it is?  What I want 
> is to have a pathdef.xml file that (a) sub-build build.xml files 
> could call to set property paths that will work in the sub-build's 
> build.xml file and (b) will work if the source tree is checked out to 
> another machine (or a different directory on my machine).
> 

As someone mentioned, the only way may be to do:
  <path id="path.for.my.prop" location="path.to.be.resolved"/>
  <property name="my.prop" refid="path.for.my.prop" />
which is really ugly.

> 2)  If the answer to question 1) is "no", would it be reasonable (or 
> desireable) to add a new task called "resolvepath" with the following 
> syntax:
> 
> <resolvepath prop="my.prop" path="path.to.be.resolved"/>
> 
> where the "path.to.be.resolved" is stored in "my.prop" after 
> resolving.  my.prop would (presumably) contain a canonical path after 
> resolution.
>

A more simple suggestion is to modify property to understand file names:

  <property name="my.prop" location="path.to.be.resolved"/>
 
> 3)  Am I correct in assuming that the present resolvePath methods 
> would not work with this scheme if the path.to.be.resolved does not 
> actually exist?  If I'm right, we would need to change resolvePath 
> (or create a new method for this purpose) to have the following 
> behavior:
> 
Java File objects do not need to point to existing things. After all you are
allowed to ask if they exist (File.exists()).

Jose Alberto

 


Mime
View raw message