> -----Original Message-----
> From: Steve Loughran [mailto:[EMAIL PROTECTED]
>
> Peter Reilly wrote:
> > This is easy to explain and it is is the manal ;-)
> >
> > Using the <ant dir="x"/> will set the basedir as a user-like property,
> > which means that
> > it cannot be overwitten subsequently - i.e. it gets "frozen".
> >
> > You need to use : <ant antfile="x/build.xml" inheritall="no"/> which
> > will set basedir property
> > as a non-user-like property.
>
> In that case I have been using <ant> wrongly, forever.
Yep! Here's the corresponding manual section:
Basedir of the new project:
The basedir value of the new project is affected by the two
attributes dir and inheritall, see the following table for details:
-- dir attr -- -- inheritAll attr. -- -- new project's basedir --
value provided true value of dir attribute
value provided false value of dir attribute
omitted true basedir of calling project
(the one whose build file
contains the <ant> task).
omitted false basedir attribute of the <project>
element of the new project
> I always use the "dir" setting as it 100% guarantees that the dir is set
> up to that of the dest, which is how I usually work. And when you call
> <ant> in a sub project, using dir, it again sets up the basedir to be
> that of the destination.
Yeah, because you were basically always overriding the sub-builds basedir,
but at the same time providing the same value. When you add subant in the
mix, then this scheme breaks, because the mechanism to override the basedir
is too strong (using a user-defined property). The sub-project, which sets
the basedir itself, can't override the value, and SubAnt which does nothing
itself with the basedir, appears to override the value, unlike stated in
the documentation.
> We do not get that same chaining semantics with ant -> subant.
SubAnt internally relies an Ant to delegate to the subbuild, but never
sets dir attribute (omitted in the table ablove), so it's the inheritAll
attribute which decide for SubAnt whether to override the basedir or not,
and in <subant>, unlike <ant>, it defaults to false.
What I take all this means is that if you chain (ant or subant) with subant,
and override the basedir in the first ant or subant (but providing a dir or
inheritAll=true in <ant>, or just inheritAll=true in <subant>), then you're
messing up the second level (or third level, etc...) subant.
Thus I come back to my question about why basedir override was implemented
in the first place. I didn't get an answer I liked so far. Maybe it's
because I always design my build/subbuilds in such a way that any basedir
override would break them, or said differently, that the build behaves the
same way when called directly, or called from a parent/master build.
--DD
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
