> From: Matthew Kuperus Heun [mailto:[EMAIL PROTECTED] > > 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
Jose Alberto Fernandez.vcf
Description: Binary data
