OK, getting closer but no cigar yet. So does a property get set on failure?
For example, if I run the following with -k, I would think it would go into
target1, target2, and then onfailure, but instead it goes into each target:
<project default="main">
<target name="target1">
<echo message="In target1"/>
<fail if="failtarget1" />
</target>
<target name="target2" unless="failure">
<echo message="In target2"/>
<copy todir="../dirThatDoesntExist">
<fileset dir="anotherDirThatDoesntExist"/>
</copy>
<fail if="failtarget2" />
</target>
<target name="target3" unless="failure">
<echo message="In target3"/>
<fail if="failtarget3" />
</target>
<target name="onsuccess" unless="failure">
<echo message="successful"/>
</target>
<target name="onfailure" if="failure">
<echo message="failure"/>
</target>
<target name="main" depends="target1,target2,target3,onsuccess,onfailure" />
</project>
________________________________
From: Matt Benson <gudnabr...@yahoo.com>
To: Ant Users List <user@ant.apache.org>
Sent: Monday, April 13, 2009 4:26:55 PM
Subject: Re: onsuccess or onfailure
--- 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, 5:05 PM
> Does trycatch have to be internal to
> a target? I tried:
>
trycatch is a task. You cannot contain targets inside a task. You can specify
any number of tasks outside of a target; these will be added to the anonymous
default target--this makes it easy to make quick & dirty buildfiles that do a
single thing, great for abusing Ant to do all sorts of things other than what
it was designed for.
> <project name="build" default="main">
> <taskdef
> resource="net/sf/antcontrib/antcontrib.properties"/>
> <trycatch>
> <try>
> <target name="main"
> depends="target1,target2,target3" />
>
> <target name="target1">
> <echo message="In target1"/>
> </target>
>
> <target name="target2">
> <echo message="In target2"/>
> <copy todir="../dirThatDoesntExist">
> <fileset
> dir="anotherDirThatDoesntExist"/>
> </copy>
> </target>
> <target name="target3">
> <echo message="In target3"/>
> </target>
> </try>
> <catch>
> <echo message="failure"/>
> <fail message="${failure}"/>
> </catch>
>
> <finally>
> <echo message="successful"/>
> </finally>
> </trycatch>
>
> </project>
>
> but it never hit my default target, flew straight into the
> catch and then to the finally... It doesn't seem there's a
> prescribed way for defining what happens after something
> fails in Ant other than leave. The way you restructured
> my code earlier never hits the onfailure target either. I
The example I gave you depends on your detecting failures and setting the
"failure" property appropriately. Once again, if all you're trying to do on
failure is send an email, you might best served by the MailLogger. If you
planned to use the keepgoing option you could use a success property instead of
a failure property:
<project default="main">
<target name="target1">
<echo message="In target1"/>
<fail if="failtarget1" />
<property name="success1" value="nobodycareswhatmyvalueis" />
</target>
<target name="target2">
<echo message="In target2"/>
<fail if="failtarget2" />
<property name="success2" value="nobodycareswhatmyvalueis" />
</target>
<target name="target3">
<echo message="In target3"/>
<fail if="failtarget3" />
<property name="success3" value="nobodycareswhatmyvalueis" />
</target>
<target name="checksuccess">
<condition property="success" value="nobodycareswhatmyvalueis">
<and>
<isset property="success1" />
<isset property="success2" />
<isset property="success3" />
</and>
</condition>
</target>
<target name="onsuccess" if="success">
<echo message="successful"/>
</target>
<target name="onfailure" unless="success">
<echo message="failure"/>
</target>
<target name="main"
depends="target1,target2,target3,checksuccess,onsuccess,onfailure" />
</project>
This example begins to get a bit silly, but it works. Each target includes a
built-in failure mechanism to play with. Specify e.g. 'ant
-Dfailtarget1=anyvalue' and the build will fail on target1. Add -k to that and
all three targets will be executed before the success/failure is also evaluated.
-Matt
> don't want the targets to keep running when something fails,
> I just want to be able to clean up shop and send an email
> with logs to the appropriate folks. Otherwise, I have to
> peek back at the command line every once in a while or wrap
> the Ant call so that I can get a return code...
>
>
>
>
> ________________________________
> From: Matt Benson <gudnabr...@yahoo.com>
> To: Ant Users List <user@ant.apache.org>
> Sent: Monday, April 13, 2009 2:46:34 PM
> Subject: Re: onsuccess or onfailure
>
>
> Those steps 1 and 2 are mutually exclusive. Personally I
> wouldn't recommend the step 2 approach. Step 2 simply
> tells you to put the jar someplace sensible so you can use
> it. I still wouldn't bind a buildfile to a directory
> location; either bundle ant-contrib with your project so
> that your buildfile can find it from its basedir, or use the
> other built-in facilities to manage included libraries.
> Specifically, read the user manual Running Ant > Library
> Directories and Running Ant > Environment Variables for
> more information on automatic library management.
>
> -Matt
>
> P.S. Never use CLASSPATH! ;)
>
> --- 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, 3:34 PM
> > I'm an old dog, but I can learn new
> > tricks (even become friends with depends).
> >
> > So I'm trying to work out the <trycatch> stuff,
> but
> > first I've got to get antcontrib wired up. I've done
> step
> > 1 which is obvious. Where is step 2 referring to
> (i.e.
> > what file do I place that code in?
> >
> > 1. Copy ant-contrib-0.3.jar to the lib
> > directory of your Ant installation. If you want to use
> one
> > of the tasks in your own project, add the lines
> > <taskdef
> >
> resource="net/sf/antcontrib/antcontrib.properties"/>
> > to your build file.
> > 2. Keep ant-contrib-0.3.jar in a
> > separate location. You now have to tell Ant explicitly
> where
> > to find it (say in /usr/share/java/lib):
> > <taskdef
> >
> resource="net/sf/antcontrib/antcontrib.properties">
> > <classpath>
> > <pathelement
> >
> location="/usr/share/java/lib/ant-contrib-0.3.jar"/>
> > </classpath>
> > </taskdef>
> >
> >
> >
> > ________________________________
> > From: Matt Benson <gudnabr...@yahoo.com>
> > To: Ant Users List <user@ant.apache.org>
> > Sent: Monday, April 13, 2009 9:18:34 AM
> > Subject: Re: onsuccess or onfailure
> >
> >
> > 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
> >
> >
> >
>
>
>
>
> ---------------------------------------------------------------------
> 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
