ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matthew Kuperus Heun <matthew.k.h...@gaerospace.com>
Subject [RFC] Suggestion for resolvepath task
Date Fri, 06 Oct 2000 13:21:44 GMT
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:matthew.k.heun@gaerospace.com>

Mime
View raw message