ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kitching Simon <>
Subject RE: if basedir absolute file name then resolving file names cause s duplicate basedirs in resulting string
Date Fri, 18 Aug 2000 14:11:58 GMT
Jesse Glick wrote:

> I find the semantics of 'dir' vs 'antFile' attributes on the <ant> task
> very confusing. The documentation is murky on how it works.

Personally, I find the current directory-related behaviour of the <ant> task
satisfactory, with the exception of the bug regarding absolute path.

I have a set of projects that I need to build, most of which can be build
just a couple of different build.xml files. So I put these commonly-used
in a common directory, then just have something like:
<ant dir="srcdir1" antfile="${buildfiledir}/buildclasses.xml" />
<ant dir="srcdir2" antfile="${buildfiledir}/buildclasses.xml" />
<ant dir="srcdir3" antfile="${buildfiledir}/buildapplet.xml" />
<ant dir="srcdir4" antfile="${buildfiledir}/buildapplet.xml" />

To summarize the *current* behaviour of the ant task (as I understand it):
* The "dir" attribute is regarded as relative to the basedir of the parent
(current) ant project or is absolute; if
  not specified, then it defaults to ".", ie same directory as parent
(current) ant project, no matter where the
  antfile points to.
* The "basedir" attribute of each subproject is whatever was specified by
the "dir" attribute
* The "antfile" is relative to the basedir of the subproject, or is absolute
(though doesn't currently work if absolute).

Note that I have carefully put the "dir" attribute *before* the antfile
attribute, so that the sequence of steps
taken to calculate the paths seems more logical. Perhaps simply changing the
order of attributes in the
ant task documentation might make this more obvious?

> -----Original Message-----
> From:	Jesse Glick []
> Sent:	Friday, August 18, 2000 3:53 PM
> To:
> Subject:	Re: if basedir absolute file name then resolving file names
> causes  duplicate basedirs in resulting string
> Kitching Simon wrote:
> > The above ant tasks generate bad antFile paths, because the path is
> > absolute. Currently,
> > only relative paths work, eg "antFile="../mybuildfile.cml" works ok.
> Somewhat related:
> I find the semantics of 'dir' vs 'antFile' attributes on the <ant> task
> very confusing. The documentation is murky on how it works.
> - If you specify only antFile, and give it a build file in a different
> directory, what is the subproject's basedir set to? That different
> directory, I assume.
> - What if the subproject's buildfile says basedir=".." or
> basedir="some/sub/dir"? Will it still work?
> - If the buildfile is called build.xml, and you give just dir, does it
> work the same or differently?
> - If you give both, then what?
> So attached is a test case. Run the upper script. In *no case* is the
> basedir attribute of the lower script honored (it seems to be ignored,
> since using both "." and "sub2" have the same effect)--I would expect
> all three cases to show sub1/sub2/ as the resolution of "." for the pwd.
> The first run (just antFile) runs in the top directory. Passing just dir
> runs in sub1, as does passing both dir and antFile. (Passing both did
> not work the same in Ant 1.1 BTW--you would still have to qualify
> antFile, otherwise it would recurse on the current script!)
> My suggested semantics: if both antFile and dir are missing, then the
> current script is used; if antFile only is given, it is treated as a
> filename for the build script relative to the current script's basedir;
> if just dir is given, it is the same as giving antFile with that dir
> plus "/build.xml"; passing both antFile and dir is a syntax error. When
> the subproject is run, it is given a basedir calculated from the
> directory in which that build script is contained, modified/replaced by
> its basedir attribute, regardless of where the master script is. This
> would make <ant> consistent in behavior with running the commandline
> e.g. "ant -buildfile sub1/build.xml" (which prints sub1/sub2 as I
> expected). Otherwise build scripts will not in general work when called
> from elsewhere, since they may expect their basedir to really be set
> where they asked and for files to exist in certain places relative to
> themselves.
> -Jesse
> -- 
> Jesse Glick   <>
> NetBeans, Open APIs  <>
> tel (+4202) 3300-9161 Sun Micro x49161 Praha CR << File:
> >> 

View raw message