If there is an actual build failure in any target execution will end, unless
you run Ant in keepgoing mode (I believe that is command-line option -k). You
could instead use ant-contrib's <try> task to catch BuildExceptions and defer
their processing until the end. Finally, note that antcall should pretty much
be used when nothing else will work. In particular it won't work for what
you're trying to do because, as antcall actually executes a different Project
instance, any properties set in called targets will not be available in your
top level/calling project. For the same reasons, antcall is a memory and time
waster. I personally consider it deprecated and haven't used antcalls since
macrodefs became available--I have not yet found the problem that (prior to Ant
1.6) required an antcall, but couldn't be solved (after Ant 1.6) with a
macrodef. If you insist you simply hate using target dependencies, despite the
fact that that's precisely what they
are for, you could consider using ant-contrib's antcallback task; this allows
properties to be set in the calling project, though it does not solve the
memory/speed issues introduced by using a separate project instance. Another
thing to note is that for those times when you really do want to use multiple
<antcall>s, you should consider using multiple nested <target> elements in a
single <antcall> for efficiency (ac antcallback does not support this,
however). Depends are really okay! They're the Ant way!
HTH,
Matt
--- On Mon, 4/13/09, Eric Fetzer <elstonk...@yahoo.com> wrote:
> From: Eric Fetzer <elstonk...@yahoo.com>
> Subject: Re: onsuccess or onfailure
> To: "Ant Users List" <user@ant.apache.org>
> Date: Monday, April 13, 2009, 9:24 AM
> Thanks Matt! So if in target2 it
> fails out, it will still make it to target3? In NAnt, when
> it fails anywhere, that's it unless there's an onfailure
> declared... Would it still work my way (I don't like
> depends because of readability):
>
> <target name="main">
> <antcall target="target1"/>
> <antcall target="target2"/>
> <antcall target="target3"/>
> <antcall target="onsuccess"/>
> <antcall target="onfailure"/>
> </target>
>
> <target name="target1">
> <echo message="In target1"/>
> </target>
>
> <target name="target2">
> <echo message="In target2"/>
> </target>
>
> <target name="target3">
> <echo message="In target3"/>
> </target>
>
> <target name="onsuccess" unless="failure">
> <echo message="successful"/>
> </target>
>
> <target name="onfailure" if="failure">
> <echo message="failure"/>
> <fail message="${failure}"/>
> </target>
>
>
>
>
>
> ________________________________
> From: Matt Benson <gudnabr...@yahoo.com>
> To: Ant Users List <user@ant.apache.org>
> Sent: Friday, April 10, 2009 2:55:24 PM
> Subject: Re: onsuccess or onfailure
>
>
> <project default="main">
>
> <target name="target1">
> <echo message="In target1"/>
> </target>
>
> <target name="target2">
> <echo message="In target2"/>
> </target>
>
> <target name="target3">
> <echo message="In target3"/>
> </target>
>
> <target name="onsuccess" unless="failure">
> <echo message="successful"/>
> </target>
>
> <target name="onfailure" if="failure">
> <echo message="failure"/>
> <!-- make it more obvious the build failed" />
> <fail message="${failure}"/>
> </target>
>
> <target name="main"
> depends="target1,target2,target3,onsuccess,onfailure" />
>
> </project>
>
> You can test the failure state by specifying
> -Dfailure=anyvalue on the command line. You might like the
> NoBannerLogger (does not log quiet/skipped targets) with
> this example. Also, as far as mailing build results goes,
> the MailLogger may help you.
>
> HTH,
> Matt
>
> --- On Fri, 4/10/09, Eric Fetzer <elstonk...@yahoo.com>
> wrote:
>
> > From: Eric Fetzer <elstonk...@yahoo.com>
> > Subject: Re: onsuccess or onfailure
> > To: "Ant Users List" <user@ant.apache.org>
> > Date: Friday, April 10, 2009, 3:45 PM
> > I don't get this Matt. Can you fix
> > the following to be what you're talking about:
> >
> > <target name="main">
> > <antcall target="target1"/>
> > <antcall target="target2"/>
> > <antcall target="target3"/>
> > <antcall target="onsuccess"/>
> > <antcall target="onfailure"/>
> > </target>
> >
> > <target name="target1">
> > <echo message="In target1"/>
> > </target>
> >
> > <target name="target2">
> > <echo message="In target2"/>
> > </target>
> >
> > <target name="target3">
> > <echo message="In target3"/>
> > </target>
> >
> > <target name="onsuccess" unless="somehow I know
> all
> > tasks were successful">
> > <echo message="successful"/>
> > </target>
> >
> >
> >
> > <target name="onfailure" unless="somehow I
> > know something failed">
> > <echo message="failure"/>
> > </target>
> >
> >
> > To me, I don't see any way to get to another target
> once it
> > fails out of one. The onsuccess, yes, but not
> > onfailure...
> >
> > Thanks for having patience with me Matt!
> >
> >
> >
> >
> >
> > ________________________________
> > From: Matt Benson <gudnabr...@yahoo.com>
> > To: Ant Users List <user@ant.apache.org>
> > Sent: Friday, April 10, 2009 9:19:44 AM
> > Subject: Re: onsuccess or onfailure
> >
> >
> > --- On Fri, 4/10/09, Eric Fetzer <elstonk...@yahoo.com>
> > wrote:
> >
> > > From: Eric Fetzer <elstonk...@yahoo.com>
> > > Subject: Re: onsuccess or onfailure
> > > To: "Ant Users List" <user@ant.apache.org>
> > > Date: Friday, April 10, 2009, 9:32 AM
> > > Sorry, I should have given you more
> > > detail. It does exactly what it says. When
> the
> > build
> > > fails (i.e. a target that isn't set for
> > onfailure="false"
> > > fails) or finishes with success, it immediately
> calls
> > the
> > > target specified. In my example, it would call
> > either the
> > > onsuccess or onfailure targets. Very useful to
> me
> > because
> > > I want to send emails, unlock files in StarTeam,
> scan
> > > logs... for onfailure, but not for success.
> >
> > In Ant you would ordinarily structure your target
> > dependencies such that onsuccess and onfailure were
> always
> > part of the graph, but would use target if/unless
> attributes
> > to en/disable them at RT. Alternately you might be
> able to
> > write a custom target Executor to do something like
> what
> > NAnt does, but I wouldn't necessarily recommend that
> > approach.
> >
> > HTH,
> > Matt
> >
> > >
> > >
> > >
> > >
> > > ________________________________
> > > From: Matt Benson <gudnabr...@yahoo.com>
> > > To: Ant Users List <user@ant.apache.org>
> > > Sent: Thursday, April 9, 2009 4:24:12 PM
> > > Subject: Re: onsuccess or onfailure
> > >
> > >
> > >
> > >
> > > --- On Thu, 4/9/09, Eric Fetzer <elstonk...@yahoo.com>
> > > wrote:
> > >
> > > > From: Eric Fetzer <elstonk...@yahoo.com>
> > > > Subject: onsuccess or onfailure
> > > > To: "Ant Users" <user@ant.apache.org>
> > > > Date: Thursday, April 9, 2009, 2:42 PM
> > > > Hi! I'm an ex-NAnt user coming over
> > > > to the Ant side. Most things are close to
> > identical,
> > > but I
> > > > have a question about something I'm not
> > finding. In
> > > NAnt,
> > > > you can create properties:
> > > >
> > > > <property name="nant.onsuccess"
> > > value="onsuccess"/>
> > > > <property name="nant.onfailure"
> > > value="onfailure"/>
> > > >
> > > > which will go to the corresponding onsuccess
> or
> > > onfailure
> > > > targets when finished based on whether it
> > succeeded
> > > or
> > > > not. I'm sure there is the equivalent in
> Ant,
> > but
> > > have
> > > > been unable to find it. Can someone please
> give
> > me a
> > > link
> > > > or such?
> > > >
> > >
> > > This smells of some NAnt-ness quite foreign to
> Ant.
> > > Personally speaking, I need more information
> about
> > what
> > > these properties are supposed to do before I can
> offer
> > any
> > > useful advice.
> > >
> > > -Matt
> > >
> > > > Thanks,
> > > > Eric
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > >
> > >
> >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: user-unsubscr...@ant.apache.org
> > > For additional commands, e-mail: user-h...@ant.apache.org
> > >
> > >
> > >
> >
> >
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: user-unsubscr...@ant.apache.org
> > For additional commands, e-mail: user-h...@ant.apache.org
> >
> >
> >
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscr...@ant.apache.org
> For additional commands, e-mail: user-h...@ant.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscr...@ant.apache.org
For additional commands, e-mail: user-h...@ant.apache.org
