Hi Folks:
ANT is great and it is really helping us get some development under control. It also seems to scale very well with project size. Thanks for making such a great tool available.
We have (or are trying to create) an automated build environment that uses a master build file and several sub-builds arranged in a tree. Several sub-builds higher up in the tree create Jar files upon which other builds depend.
I set properties for the path of each of these Jar files in each of the build.xml files. Every build.xml file has properties defined which contain the paths of the Jars upon which the sub-build depends. The path is defined relative the the basedir of the build.xml file. So, they look like this
In one build.xml file, they might look like this:
<property name="jarOne.jar" value="../../jars/jarOne.jar"/> <property name="jarTwo.jar" value="../../../jars/jarTwo.jar"/>
In a sub-build's build.xml file, they might look like this:
<property name="jarOne.jar" value="../../../jars/jarOne.jar"/> <property name="jarTwo.jar" value="../../../../jars/jarTwo.jar"/>
This scheme is laborious and error-prone. I'd like to have a pathdef.xml file located at the top of my source tree that would define these paths and set them in properties that would be available to all sub-build build.xml files. The sub-build build.xml files would call <ant antfile="../pathdef.xml"/> in init targets.
However, if I use relative paths in pathdef.xml, the sub-build build.xml files won't resolve the path correctly relative to it's basedir when the property is actually used in, say, a <jar> task. If I define the properties in pathdef.xml in an absolute sense, the builds won't work if I check out the repository to another machine or a different directory on my machine.
Some questions:
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).
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.
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:
a) try to get the canonical path of "path.to.be.resolved"
b) if a) fails, try to get the canonical path of "path.to.be.resolved".getParent().
c) keep working up the tree until canonicalPath(getParent()) succeeds and then append the rest of the path (the pieces that didn't resolve) to the part that did resolve.
d) If we get to the top of the tree without resolving anything, simply set
"my.prop" to the original value of "path.to.be.resolved"
This scheme would be really helpful if, say you knew you were going to create a jar later in the build. It's parent directory exists, but the jar doesn't exist because you wiped it out with "ant clean" before starting the build process.
Comments or question welcome.
Cheers,
Matt --
--
Matthew Kuperus Heun Global Aerospace Corporation +1 (978) 922-7115 (voice & fax) <http://www.gaerospace.com> <mailto:[EMAIL PROTECTED]>
