Stefan,
>
> On Thu, 05 Jul 2001, dave young <[EMAIL PROTECTED]> wrote:
>
> > <task name="grind">
>
> You mean <target>, no?
d'oh!! i knew i should have tested the darned file out before posting
it!!
yup, i do mean <target> and not <task>. :-)
> > <available file="archive-format-alpha.tar.gz"
> > property="alpha.present"/>
> > <available file="archive-format-beta..tar.gz"
> > property="beta.present"/>
> > <antcall target="setup_alpha_if_present"/>
> > <antcall target="setup_beta_if_present"/>
> > <echo message="version is ${version}"/>
> > </task>
> >
> > <task name="setup_alpha_if_present" if="alpha.present">
> > <property name="version" value="alpha"/>
> > <echo "in setup_alpha version=${version}"/>
> > </task>
> >
> > ant i enter the command; ant grind
> > i would expect to see;
> > in setup_alpha version=alpha
> > version=alpha
> >
> > but instead i see;
> > in setup_alpha_version=alpha
> > version=${version}
>
> If you use <antcall> or <ant>, you run a completely separate build
> process that is a child of your "normal" build process. This child
> inherits properties but has no (easy and clean) ways to pass
> properties back up.
>
> In your case, you probably don't want to use antcall at all, but the
> depends attribute of target.
ok, this makes sense now. i have modified my build.xml file to use
dependancies instead and those settings "stick". i can accept that
invoking an antcall is setting up a child whose variable/property
settings do not propogate back to the caller.
thanks again.
best regards,
dave.
>
> Stefan
