Erskine, Chris wrote:
So, if I understand you right, you are saying that because the build.xml file was not read from the file system, I will have problems assuming where the other files like .properties files will be? I guess that I would have the same types of issues on things like where the source files are located and where I want to build to.
I think the real problem is that the <import> tag has some assumptions that are broken by reading from non-locatable sources. From the ant manual:
Parameters
-------------------
file -- The file to import. If this is a relative file name, the file name will be resolved relative to the importing file. Note, this is unlike most other ant file attributes, where relative files are resolved relative to ${basedir}.
optional -- If true, do not stop the build if the file does not exist, default is false.
So, <import> resolves NOT from ${basedir}, but from the location of the build.xml file. I expect this breaks when build.xml wasn't loaded from a file (although I haven't tested it). So, "Don't Do That". It seems that <import> is a special case, as most (all?) other tasks will be resolving files relative to ${basedir}. (Maybe it's worthwhile to have a version of import that resolves to basedir?) The ant.file property causes some headaches as well.
So, I suppose the answer is that general purpose build scripts (which may assume that the live on a filesystem) break when not in a filesystem (not surprising given that you've broken an assumption). On the other hand, self-contained build scripts that don't reference ant.file seem to be perfectly content being loaded in an unorthadox manner. This is an OK limitation for my application; if others are interested in this kind of thing, perhaps a simple docuentation fix is all that is necessary to allow InputStream parsing? OTOH, perhaps no one but me cares....
Robert Dockins
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
